如何保证kafka无消息丢失

kafka无消息丢失的理解：

  Kafka 只对“已提交”的消息（committed message）做有限度的持久化保证。

“已提交”

  什么叫“已提交”的信息？当kafka的若干个broker成功的接收消息并写入日志文件后，他们会告诉生产者这条消息已成功提交。此时，这条消息才算已提交的消息。
  此处的若干个broker是要看你的配置，你对“已提交”的定义。你可以配置，只要有一个broker提交成功就算已提交，也可以设置所有broker提交成功才算已提交。

有限度的保证

  就像”地球不爆炸，我们不放假“一样，你要让kafka能做持久化保证，就必须保证有至少一个broker还可以运行。

消息丢失的情况：

生产者丢失数据。

  生产者丢失数据，应该是被抱怨最多的数据丢失场景了。当我们使用生产者向kafka集群发送了一条消息后，竟然发现消息没有被保存。此时我们就要骂他了。
  但是呢，这种情况其实是我们误会它了，接下来我们来分析原因：
  目前，kafka producer 是异步发送消息的，也就是如果你使用的是 producer.send(msg)这个API,那它会立即返回，不过此时你不能认为消息已发送成功。这个API是发送之后不管是否发送成功的。
  使用这种方式，有哪些情况会发生消息没有发送成功呢？原因有很多，例如网络抖动，消息根本没到broker端；或消息本身不合格导致broker拒收等。所以kafka这个锅背的冤呀。
  解决：要解决也不难，只需要让producer永远使用带有回调通知的发送API，就可以了。也就是使用producer.send(msg,callback)。它可以准确的告诉你你的消息是否真的提交成功了。

消费者程序丢失数据

  Consumer端丢失数据主要体现在要消费的数据不见了，Consumer程序有个“位移的概念”，表示的是这个Consumer当前消费到的Topic分区的位置。

  此处的位移类似我们看书时的书签。如果我们决定今天上午要看完前一百页，在看之前就把书签放到了100页的位置，但是我们有事，导致我们之看完了90页，之后再回来看的时候，90页到100页之间的数据我们就丢失了。
  同理，kafka的Consumer端的消息丢失就是这么回事。要解决也很简单：维持先消费消息（阅读），再更新位移（书签）的顺序即可。但是这样也出现了另一个问题：可能出现重复消费。
  Consumer除了上面的可能之外，还有一种可能导致消息丢失：使用多线程消费时，Consumer 程序自动地向前更新位移，如果某个线程意外终止了，没有完成工作，但是位移被提交了。就会出现数据丢失。
解决方式：如果是多线程异步处理消费消息，Consumer程序不要开启自动提交位移，而是要应用程序手动提交位移。

总结：

如何避免kafka消息丢失：
1：不要使用producer.send(msg),而是使用producer.send(msg,callback)。记住，一定要使用带有回调通知的send方法。
2：设置acks = all 。acks是Producer的一个参数，代表你对已提交”消息的定义。设置成all,代表所有副本Broker都接收到消息才算已提交。
3：设置retries为一个较大的值。他也是一个Producer的参数，对应自动重试。
4：设置unclean.leader.election.enable = false。broker端参数，此设置不允许落后太多的broker竞选Leader。
5：设置replication.factor>=3。broker端参数，此设置是让消息多保存几份。
6：设置min.insync.replicas > 1。broker端参数，控制消息至少写入一个副本才算“已提交”。
7：确保repliication.factor>min.insync.replicas。如果两者相等，那只要有一个副本挂掉整个分区就无法正常工作了。
8：确保消费完成再提交。将enable.auto.commit设置成false。并采用手动提交位移。