目录
编辑
今天我们深度剖析一下kafka丢失消息的原因和怎么预防其丢失数据。
kafka角色介绍
kafka是一个分布式架构的消息队列，其主要由三部分组成 Producer、Broker、Consumer三部分组成。
Producer：消息的生产者
Broker: 消息的中间人（将消息进行同步并持久化数据）。
Consumer：消息的消费者
kafka消息丢失的场景分析
场景一：Producer端
producer负责生产消息，生产的消息要发送给Broker端，怎么确定消息有没有发出呢？
在kafka的设计中Producer有ACK 机制,我来解释这个机制
request.required.acks有三个值 0,1，-1/all
- acks = 0：由于发送后就自认为发送成功，这时如果发生网络抖动， Producer 端并不会校验 ACK 自然也就丢了，且无法重试。
- acks = 1：消息发送 Leader Parition 接收成功就表示发送成功，这时只要 Leader Partition 不 Crash 掉，就可以保证 Leader Partition 不丢数据，但是如果 Leader Partition 异常 Crash 掉了， Follower Partition 还未同步完数据且没有 ACK，这时就会丢数据。
- acks = -1 或者 all： 消息发送需要等待 ISR 中 Leader Partition 和 所有的 Follower Partition 都确认收到消息才算发送成功, 可靠性最高, 但也不能保证不丢数据,比如当 ISR 中只剩下 Leader Partition 了, 这样就变成 acks = 1 的情况了。
场景二: Broker端
Kafka Broker 集群接收到数据后会将数据进行持久化存储到磁盘，为了提高吞吐量和性能，采用的是「异步批量刷盘的策略」，也就是说按照一定的消息量和间隔时间进行刷盘。首先会将数据存储到 「PageCache」 中，至于什么时候将 Cache 中的数据刷盘是由「操作系统」根据自己的策略决定或者调用 fsync 命令进行强制刷盘，如果此时 Broker 宕机 Crash 掉，且选举了一个落后 Leader Partition 很多的 Follower Partition 成为新的 Leader Partition，那么落后的消息数据就会丢失。
场景三：Consumer端
消息消费流程可以分为两个阶段：
- 获取元数据并从 Kafka Broker 集群拉取数据。
- 处理消息，并标记消息已经被消费，提交 Offset 记录。
- 可能使用的「自动提交 Offset 方式」
- 拉取消息后「先提交 Offset，后处理消息」，如果此时处理消息的时候异常宕机，由于 Offset 已经提交了, 待 Consumer 重启后，会从之前已提交的 Offset 下一个位置重新开始消费， 之前未处理完成的消息不会被再次处理，对于该 Consumer 来说消息就丢失了。
- 拉取消息后「先处理消息，在进行提交 Offset」， 如果此时在提交之前发生异常宕机，由于没有提交成功 Offset， 待下次 Consumer 重启后还会从上次的 Offset 重新拉取消息，不会出现消息丢失的情况， 但是会出现重复消费的情况，这里只能业务自己保证幂等性。
