内容
- producer消息不丢失
- consumer消息不丢失
生产端消息不丢失
- 不要使用 producer.send(msg)，而要使用 producer.send(msg, callback)。记住，一定要使用带有回调通知的 send 方法。callback可以处理消息发送之后的逻辑，不一定就是失败的逻辑。retries是预防那种瞬时错误的，比如网络抖动这种问题；
- 设置 retries 为一个较大的值。这里的 retries 同样是 Producer 的参数，当出现网络的瞬时抖动时，消息发送可能会失败，此时配置了 retries > 0 的 Producer 能够自动重试消息发送，避免消息丢失。
- 设置 acks = all (1,0,-1,all), -1等同于all。all：所有的isr 副本都得相应成功才是成功，0 表示不管响应成功与否都返回给客户端成功，1 表示leaser要写入成功，才告诉producer客户端成，默认值是1，是吞吐率和可用性的折中方案。
- 设置 min.insync.replicas > 1。这是 Broker 端参数，控制的是消息至少要被写入到多少个副本才算是“已提交”。 min.insync.replicas规定了isr的数量，例如 min.insync.replicas为2，代表着isr副本数量要求为2，即: acks=all时, 要求2个副本写入成功才得行
- 设置 unclean.leader.election.enable = false。这是 Broker 端的参数，它控制的是哪些 Broker 有资格竞选分区的 Leader。如果一个 Broker 落后原先的 Leader 太多，那么它一旦成为新的 Leader，必然会造成消息的丢失。故一般都要将该参数设置成 false，即不允许这种情况的发生。
- 设置 replication.factor >= 3。这也是 Broker 端的参数，规定了分区副本数。
- 确保 replication.factor > min.insync.replicas。如果两者相等，那么只要有一个副本挂机，整个分区就无法正常工作了。我们不仅要改善消息的持久性，防止数据丢失，还要在不降低可用性的基础上完成。
- 推荐设置成 replication.factor = min.insync.replicas + 1。确保消息消费完成再提交。
消费端消息不丢失
- enable.auto.commit：最好把它设置成 false，代表是不自动提交消费位移，采用手动提交位移的方式来消费数据。
引用： - 《Kafka核心技术与实战_胡夕》
