kafka（三：无消息丢失配置怎么实现）

Kafka 只对“已提交”的消息做有限度的持久化。

这里已提交指的是kafka的若干个broker成功接收到消息并成功写入到日志文件，他们就会告诉生产者这条消息提交成功。

有限度指的是kafka并不能保证任何情况下都能保证消息不丢失。

消息丢失的例子：

     1 生产者Producer 丢失消息。 可能的场景有网络抖动，导致消息压根就没有发送到 Broker 端，或者消息本身不合格导致 Broker 拒绝接收（比如消息太大了，超过了 Broker 的承受能力），当然如果broker宕机了也是发送不成功的。所有这里涉及到了ack机制。

ack=0时，生产者向broker发送消息后不需要回调反馈。高效但是容易丢失数据。  

ack=1时，同步发送，这是kafka的默认值，broker里的leader分区接受到消息后立马返回ack。生产者收到后知道消息发送成功。

ack=-1时，broker中的分区下的ISR副本都同步完成才会返回ack，这种场景虽然数据同步率高但是性能差。

    2  消费者程序丢失数据。 

         2.1 先更新了offset，提交给ZK后，突然宕机，还没消费消息。所以针对这种情况要维持先消费消息，再提交consumer offset，虽然会带来数据重复消费问题。 

         2.2 Consumer设置了自动提交位移，消息并没有真正被消费，但是自动提交了Consumer offset，所以还是设置为手动提交相对安全。

 

如下配置kafka消息不丢失的配置：

1 不使用 producer.send(msg)，而要使用 producer.send(msg, callback)。

2 设置 acks = all。acks 是 Producer 的一个参数，设置成 all表明所有副本 Broker 都要接收到消息，该消息才算是“已提交”。

3 设置 retries 为一个较大的值。当出现网络的瞬时抖动时，消息发送可能会失败，配置了 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 可以提升消息持久性。

7 确保 replication.factor > min.insync.replicas。如果两者相等，那么只要有一个副本挂机，整个分区就无法正常工作了。不仅要改善消息的持久性，防止数据丢失。设置成 replication.factor = min.insync.replicas + 1。

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