2024年最新Kafka数据丢失原因及解决方案_kafka消息丢失解决方案，差点挂在第四面

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

解决方法：更换调用方式，不使用异步发送，使用带回调通知函数的方法进行发送消息，网络波动和消息过大，可以调整Producer端重试次数和消息大小。

丢失原因：Kafka默认ack设置为1，会存在数据丢失问题。(ack为0也会存在丢数据问题)

解决方法：修改ack设置为-1。(可以结合幂等性做到Exactly Once)

Broker端

丢失原因：数据从Producer端push过来后，Broker端需要将数据持久化存储到磁盘中，消息存储是异步存储的，即按照一定的消息数量和间隔时间进行存储，数据会先放在 PageCache 中，如果在存储的时候Broker宕机，此时选举了一个落后Leader Partition 很多的 Follower Partition 成为新的Lerder Partition，那么落后的消息就会丢失。

解决方法：修改参数，设置有资格成为Leader的Follower(落后太久的不要)，设置分区数≥3(Leader宕机后可以有Follower补上)，设置消息至少要被写入成功到ISR多少个副本才算“已提交”。

Consumer端

丢失原因：Consumer拉取消息后最终处理完需要提交 Offset，提交Offset有以下三种方式：

1. 自动提交Offset。
2. 拉取消息后，先提交offset、再处理消息，如果此时处理消息的时候宕机，由于Offset已提交，Consumer重启后会从之前已提交的offset 下一个位置开始消费，之前未处理的消息不会被再次处理，对于Consumer来说消息已经丢失。
3. 拉取消息后，先处理消息、再提交Offset，如果此时在提交之前宕机，由于Offset没有提交，Consumer重启后会从上次的Offset重新拉取消息，不会丢失数据，但会出现重复消费的情况，这里只能业务自己保证幂等性。

方式2会导致数据丢失。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**