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

最新推荐文章于 2024-07-19 07:33:20 发布

chad__chang

最新推荐文章于 2024-07-19 07:33:20 发布

阅读量1.8k

点赞数 2

分类专栏： kafka 文章标签： kafka java 分布式

本文链接：https://blog.csdn.net/Chad_it/article/details/127266714

版权

kafka 专栏收录该内容

7 篇文章 0 订阅

订阅专栏

🍬 博主介绍

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

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

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

🎉欢迎关注💗一起学习👍一起讨论⭐️一起进步📝欢迎评论

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

今天我们深度剖析一下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, 最大限度保证系统可用性。