【kafka技术篇】kafka数据到底会不会丢失？

博主介绍 

‍ 博主主页：淼淼_喵的博客_CSDN博客-Zookeeper,Hadoop,大数据技术领域博主

✨主攻领域：【大数据开发】【数据仓库】 【ETL】 【数据分析】【面试分析】

点赞➕评论➕收藏 == 养成习惯（一键三连）

欢迎关注一起学习一起讨论⭐️一起进步欢迎评论

作者水平有限，欢迎各位大佬指点，相互习进步！

目录

博主介绍 

kafka角色介绍

kafka消息丢失的场景分析

场景一：Producer端

场景二: Broker端

场景三：Consumer端

kafka如何最大限度的保证数据不丢失

Producer端

Broker端

Consumer端

---

 

今天我们深度剖析一下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 重新拉取消息，不会出现消息丢失的情况， 但是会出现重复消费的情况，这里只能业务自己保证幂等性。

kafka如何最大限度的保证数据不丢失

Producer端

1. 调用方式

（1）网络抖动导致消息丢失，Producer 端可以进行重试。

（2）消息大小不合格，可以进行适当调整，符合 Broker 承受范围再发送。

2. ACK 确认机制

将 request.required.acks 设置为 -1/ all

3. 重试次数 retries

retries = Integer.MAX_VALUE
max.in.flight.requests.per.connection = 1

解读： Producer 端就会一直进行重试直到 Broker 端返回 ACK 标识，同时只有一个连接向 Broker 发送数据保证了消息的顺序性。

4. 重试时间 retry.backoff.ms

发送超时的时候两次发送的间隔，避免太过频繁重试，默认值为100ms, 推荐设置为300ms。

Broker端

Broker端丢失数据是由于其刷盘是异步刷盘的，kafka先把数据存储到内存页中，再进行刷盘，而且没有提供同步刷盘的策略，kafka也注意到这一点，所以其分区多副本机制也是为了最大限度的让数据不丢。

我们可以通过以下参数配合来保证：

1. unclean.leader.election.enable ：

该参数表示有哪些 Follower 可以有资格被选举为 Leader , 如果一个 Follower 的数据落后 Leader 太多，那么一旦它被选举为新的 Leader， 数据就会丢失，因此我们要将其设置为false，防止此类情况发生。

2. replication.factor ：

该参数表示分区副本的个数。建议设置 replication.factor >=3, 这样如果 Leader 副本异常 Crash 掉，Follower 副本会被选举为新的 Leader 副本继续提供服务。

3. min.insync.replicas ：

该参数表示消息至少要被写入成功到 ISR 多少个副本才算"已提交"，建议设置min.insync.replicas > 1, 这样才可以提升消息持久性，保证数据不丢失。

另外我们还需要确保一下 replication.factor > min.insync.replicas, 如果相等，只要有一个副本异常 Crash 掉，整个分区就无法正常工作了，因此推荐设置成： replication.factor = min.insync.replicas +1, 最大限度保证系统可用性。

Consumer端

设置参数 enable.auto.commit = false, 采用手动提交位移的方式。

另外对于消费消息重复的情况，业务自己保证幂等性, 保证只成功消费一次即可。

参考文章连接：

刨根问底: Kafka 到底会不会丢数据？