Kafka如何保证消息不丢失？_kafka消费者如何保证消息不丢失

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

---

前言

提示：这里可以添加本文要记录的大概内容：

消息丢失是实际生产环境中，比较容易出现的场景。如何进行规避是常常需要考虑的解决方案；

---

提示：以下是本篇文章正文内容，下面案例可供参考

一、消息丢失是如何产生的？

思考这个问题前，需要梳理清楚【消息发送】到【消息被消费】的整个过程：

也就是消息丢失发生的环节有三个：
1.生产者发送消息到broker丢失；
2.broker存储到磁盘失败，造成的消息丢失；
3.消费者从broker接收消费丢失；

实际生产中，解决消息丢失就需要从这三个场景进行排查，确认数据是在哪个环节下，导致了数据的丢失；

二、解决方案

1.生产者环节丢失

生产者环节发送失败导致的丢失，导致的原因可能是网络波动的原因，或是kafka节点故障的原因；

生产者发送消息的方式有两种： 同步 与 异步；
【解决方案】：
采用异步推送消息的方式，因为消息异步推送后，会有一个回调函数，根据回调函数的情况可以对消息进行补发；
此外，还可以设置消息重试次数；

代码如下：

2.Broker存储环节丢失

Broker存储环节，kafka对此有一个发送确认机制acks;
结合考虑kafka集群的情况下；

【解决方案】
acks发送确认机制有三种模式：

默认acks=1,只要集群leader节点，收到消息就响应成功；
acks=all，可以避免在极端情况下，消息在存储环节出现问题，但是要综合考虑其性能[不建议]；

该处使用的url网络请求的数据。

3.消费者环节丢失

该环节丢失原因： 节点重平衡 和 偏移量自动提交导致的；
【消费者节点重平衡】可以简单的理解为，一个消费者组中，有一个消费者挂了，接着另一个消费者会接班之前的消费工作；
【偏移量自动提交】：每次poll数据之后，消费者默认每隔5s就会提交一次已消费的偏移量；

会导致一下情况：
【重复消费】： 消费者节点宕机之前，还未来得及提交偏移量，重平衡之后，新分配的消费者，按照之前的偏移量进行消费从而导致了重复消费；
【消费丢失】：消费者节点宕机之前，提交了偏移量，但是实际的消费偏移量还未到达提交的偏移量，从而导致了消费丢失；

【解决方案】：
禁用自动提交偏移量，改为手动：
enable-auto-commit:false

代码如下：

【扩展】为什么采用了 异步 +同步的方式？
因为 同步提交的时候，消费端的程序会处于阻塞状态，进而会影响系统数据的吞吐量；
而 异步提交方式，虽然解决了提交偏移量阻塞的问题，但是是没有自动重试机制的，会出现一定的风险，
所以二者相组合使用，进行互补；

总结

提示：这里对文章进行总结：
以上就是今天要讲的内容，总共从三个环节对消息丢失进行的处理：发送方，broker存储， 消费方；