kafka无消息丢失配置

kafka在什么情况下才能保证消息不丢失？

一句话概括，kafka只对“已提交”的消息（committed message）做有限度的持久化保证。

已提交消息：当kafka若干个broker成功地接收到第一条消息并写入到日志文件后，它们会告诉生产者程序这条消息已成功提交。此时，这条消息在kafka看来就正式成为“已提交”消息了。你可以选择只要有一个broker成功保存该消息就算是已提交，也可以是令所有broker都成功保存该消息才算是已提交。

有限度的持久化保证：也就是说kafka不可能保证任何情况下都做到不丢失消息。

总结下，kafka是能做到不丢失消息的，只不过这些消息必须是已提交的消息，而且还要满足一定的条件。

1、不要使用producer.send(msg),而要使用producer.send(msg，callback)。记住，一定要使用带有回调通知的send方法。

2、设置acks=all。acks是producer的一个参数，代表了你对“已提交”消息的定义。如果设置成all，则表明所有副本broker都要接收消息，该消息才算是“已提交”。这是最高等级的“已提交”定义。

3、retries为一个较大的值。这里的retries同样是producer的参数，对应producer自动重试。当出现网络瞬时抖动时，消息发送可能会失败，此时配置了retries>0的producer能够自动重试消息发送，避免消息丢失。

4、设置unclean.leader.election.enable = false。这是broker端的参数，它控制的是那些broker有资格竞选分区的leader。如果一个broker落后原先的leader太多，那么它一旦成为新的leader，必然会造成消息的丢失。故一般都要将该参数设置成false，即不允许这种情况的发送。

5、设置replication.factor >= 3。这也是broker端参数。这里想表述的是，最好将消息多保存几份，毕竟目前防止消息丢失的主要机制是冗余。

6、设置min.insync.replicas > 1。broker端参数，控制的是消息至少要被写入到多少个副本才算“已提交”。设置成大于1可以提升消息持久性。在实际环境中千万不要使用默认值1。

7、确保replication.factor > min.insync.replicas 。如果两者相等，那么只要有一个副本挂机，整个分区就无法正常工作了。我们不仅要改善消息的持久性，防止数据丢失，还要在部降低可用性的基础上完成。推荐replication.factor = min.insync.replicas + 1.

8、确保消息消费完成再提交。consumer端有个参数enable.auto.commit，最好把它设置成false，并采用手动提交位移的方式。

replication.factor = min.insync.replicas + 1。