前言：

使用消息中间件时，我们遇到最头疼的事就消息丢失，小则影响程序错误，大则影响到某个重要业务失败。如果kafka配置不当或者使用不当，是很有可能出现消息丢失的。本篇博文重点探讨主要的kafka消息丢失的场景及我们应该如何配置kafka参数来避免消息的丢失。

消息丢失的场景

消息丢失无非分为3种，生产端消息丢失、kafka-broker端消息丢失、服务端消息丢失。

Kafka对于消息丢失这件事，只做了如下承诺，kafka只对已提交的消息做有限度的持久化保证。

生产者消息丢失

那生产者丢失，大多数就是因为，生产者不确定消息是否已经提交成功。如果使用不带

回调通知的send方法的话producer.send(msg)，就无法保证消息被成功。所以我们应该使用带回调函数的send方法producer.send(msg,callback),这样我们就可以监听消息的发送情况，然后做有效的重试，确保消息都发送成功。

Broker消息丢失

对于kafka服务器端消息丢失，相对来说概率是比较小的，kafka作为一个成熟的中间件，经受业界的认可，但是需要注意，消息在borker中是由存在时长的，超过这个时间，默认会删除这些消息，另外对于分区的副本数也要进行合理设计，避免因为某一台机器的硬盘别破坏掉后，导致消息丢失。

消费者消息丢失

消费者消费丢失，大多数的场景为位移提交出现了问题，比如在消费者异步多线程消费消息，其中有个处理失败，位移提交失败，就会导致这个线程处理的消息丢失。

消息丢失问题排查

对于消息丢失的问题，首先，我们应该建立完整的日志，在消息发送前和发送后、消费前后分别计日志，建立告警机制。

无消息丢失配置：

不要使用producer.send(msg)，而要使用producer.send(msg, callback)。记住，一定要使用带有回调通知的send方法。
设置acks = all。acks是Producer的一个参数，代表了你对“已提交”消息的定义。如果设置成all，则表明所有副本Broker都要接收到消息，该消息才算是“已提交”。这是最高等级的“已提交”定义。
设置retries为一个较大的值。这里的retries同样是Producer的参数，对应前面提到的Producer自动重试。当出现网络的瞬时抖动时，消息发送可能会失败，此时配置了retries > 0的Producer能够自动重试消息发送，避免消息丢失。
设置unclean.leader.election.enable = false。这是Broker端的参数，它控制的是哪些Broker有资格竞选分区的Leader。如果一个Broker落后原先的Leader太多，那么它一旦成为新的Leader，必然会造成消息的丢失。故一般都要将该参数设置成false，即不允许这种情况的发生。
设置replication.factor >= 3。这也是Broker端的参数。其实这里想表述的是，最好将消息多保存几份，毕竟目前防止消息丢失的主要机制就是冗余。
设置min.insync.replicas > 1。这依然是Broker端参数，控制的是消息至少要被写入到多少个副本才算是“已提交”。设置成大于1可以提升消息持久性。在实际环境中千万不要使用默认值1。
确保replication.factor > min.insync.replicas。如果两者相等，那么只要有一个副本挂机，整个分区就无法正常工作了。我们不仅要改善消息的持久性，防止数据丢失，还要在不降低可用性的基础上完成。推荐设置成replication.factor = min.insync.replicas + 1。
确保消息消费完成再提交。Consumer端有个参数enable.auto.commit，最好把它设置成false，并采用手动提交位移的方式。就像前面说的，这对于单Consumer多线程处理的场景而言是至关重要的。