一、kafka高可用
二、数据丢失
1）消费端弄丢了数据
Kafka默认位移提交方式是自动提交，每隔5秒提交一次，自动位移提交在正常情况下不会发生消息丢失或重复消费的现象，但你拉取到消息后，消费者端消息需要入库，处理速度较慢，此时到达了自动提交时间，消息自动提交，此时就会有两种情况，一是后续程序出现异常，数据还没来得及入库，程序恢复后，未入库的消息就相当于丢失了。二是后续程序正常执行完，但此时程序处理时间已经超过自动提交时间，kafka会默认自动提交失败，消息被重新分配到分区中，造成数据重复。丢失和重复问题都可以将自动提交改为手动提交来解决。丢失还可以通过捕获异常时，将该条消息入库，做定时任务重新发送给kafka继续消费。
消费者端手动提交方式提供了两种，commitSync()同步提交方式和commitAsync()异步提交方式。commitSync()同步提交方式在调用时Consumer程序会处于阻塞状态，提交失败会进入重试状态，这样会对消费者的性能有一定的影响，commitAsync()异步提交方式在执行后会立刻返回，不会被阻塞，但是它也有相应的问题产生，如果异步提交失败后，无法重试。我们可以把同步提交和异步提交相结合，以达到最理想的效果。
2）kafka弄丢了数据
这块比较常见的一个场景，就是kafka某个broker宕机，然后重新选举partiton的leader时。大家想想，要是此时其他的follower刚好还有些数据没有同步，结果此时leader挂了，然后选举某个follower成leader之后，他不就少了一些数据？这就丢了一些数据啊。
生产环境也遇到过，我们也是，之前kafka的leader机器宕机了，将follower切换为leader之后，就会发现说这个数据就丢了
所以此时一般是要求起码设置如下4个参数：
给这个topic设置replication.factor参数：这个值必须大于1，要求每个partition必须有至少2个副本。
在kafka服务端设置min.insync.replicas参数：这个值必须大于1，这个是要求一个leader至少感知到有至少一个follower还跟自己保持联系，没掉队，这样才能确保leader挂了还有一个follower吧。
在producer端设置acks=all：这个是要求每条数据，必须是写入所有replica之后，才能认为是写成功了。
在producer端设置retries=MAX（很大很大很大的一个值，无限次重试的意思）：这个是要求一旦写入失败，就无限重试，卡在这里了。
我们生产环境就是按照上述要求配置的，这样配置之后，至少在kafka broker端就可以保证在leader所在broker发生故障，进行leader切换时，数据不会丢失。
3）生产者会不会弄丢数据
如果按照上述的思路设置了ack=all，一定不会丢，要求是，你的leader接收到消息，所有的follower都同步到了消息之后，才认为本次写成功了。如果没满足这个条件，生产者会自动不断的重试，重试无限次。
三、数据重复
除上述造成消息重复的原因外，还有一种情况就是消费消息时，还没自动提交时，程序发生异常，消息没有来得及提交，程序恢复后，会重复消费。除将自动提交改为手动提交外，还可使用保证消息消费的幂等性的方式解决。
保证消费消息幂等性
1）如果你是要插入mysql中，可以对其设置唯一键，插入重复的数据只会插入报错，不会有重复数据产生
2）如果你是要写入redis中，每次都是set操作，可以保证幂等性
如何保证消息消费是幂等性的，需要结合具体的业务来看。
四、Kafka为什么这么快？
1）消息压缩
Kafka在对消息进行压缩，Producer 端压缩、Broker 端保持、Consum进行解压缩。它秉承了用时间去换空间的思想，具体来说就是用CPU时间去换磁盘空间或网络I/O传输量，希望以较小的CPU开销带来更少的磁盘占用或更少的网络I/O传输。Kafka支持多种压缩算法，如GZIP、Snappy 和 LZ4。
2）数据读写
Kafka会把收到的消息都写入到磁盘中，它绝对不会丢失数据。因为磁盘是机械结构，每次读写都会寻址->写入，其中寻址是一个“机械动作”，它是最耗时的。所以磁盘最讨厌随机I/O，最喜欢顺序I/O。为了提高读写硬盘的速度，Kafka就是使用顺序I/O。
五、消息队列时间开销最大的在哪儿？
根据上面对Kafka的分析，可以类推作为一个消息中间件所需的时间开销主要在以下两个方面：1）消息读写 2）网络传输
六、如何顺序消费
先看看顺序会错乱的俩场景
（1）rabbitmq：一个queue，多个consumer，这不明显乱了
（2）kafka：一个topic，一个partition，一个consumer，内部多线程，这不也明显乱了
那如何保证消息的顺序性呢？
（1）rabbitmq：拆分多个queue，每个queue一个consumer，就是多一些queue而已，确实是麻烦点；或者就一个queue但是对应一个consumer，然后这个consumer内部用内存队列做排队，然后分发给底层不同的worker来处理
（2）kafka：一个topic，一个partition，一个consumer，内部多线程消费，写N个内存queue，然后N个线程分别消费一个内存queue即可
网友评论