kafka版本：0.10.2
问题描述
上篇文章中，我们在producer代码里增加了reties参数，看似解决了partition leader选举带来的程序异常问题， 但实际隐藏了一个更为严重的问题：leader 选举过程中，producer 重试发送过程中，数据存在丢失的现象。
设置如下三个参数值，方可保证发送数据不丢失
- unclean.leader.election.enable=false （在server.properties文件中配置）
- min.insync.replicas=总副本数-1 ，即最小同步副本个数=总副本个数-1（在server.properties文件中配置）
- acks=-1/all，即当所有isr副本数全部收到消费之后再提交ack （在producer端代码里配置）
考虑在使用上述参数默认值的情况下，消息为什么会丢失？
unclean.leader.election.enable=true ：表示当该分区所有副本代理都下线的情况下，Kafka 会选第一个上线的代理作为 leader，而不管它下线之前是不是在 ISR中，那么如果这个新 leader 下线之前并不是 leader 或者不在 ISR 中，有一部分消息便丢失了。我们设置成 false,可以保证非 ISR 节点不可以参与选举。
ack=1，即当leader收到消息后，就认为消息发送成功了，不关心其他isr副本是否接收到。注意是isr(在线副本) 而不是asr（所有副本）
min.insync.replicas=1 ： 最小同步副本数默认为1，producer在生产的时候需要确认broker节点是否满足最小同步副本数，即 isr节点的个数是否>=1。满足，才认为发送成功，不满足，produer端会抛出错误，Error: NOT_ENOUGH_REPLICAS 。当 min.insync.replicas=副本数-1，这样便达到了消息发送成功的最强保障。
结论：unclean.leader.election.enable=false,Kafka 会在该分区所有副本代理都下线的情况下，从 ISR 中选择第一个上线的代理作为 leader。ack=-1 和 min.insync.replicas= 总副本数-1共同作用：要求生产时，需要得到该分区所有在线副本代理的确认，并且确认在线副本数要大于等于（副本数-1），这样就保证了每次生产，有绝大多数副本代理确认收到消息后才认为消息已成功写入 Kafka。这样如果在非常情况下进行 leader 选举，Kafka 既能很快恢复，也保障了数据不丢失。
学无止境
- isr : 已同步的副本集，是说在一段时间内和leader同步的副本们，那当数据量吞吐量一旦上来，producer生产遇到leader选举，还会不会丢数？
- 遇到kafka集群不健康，producer发送遇到leader选举，重试过程中，还是遇到了最小同步副本数不满足的情况，依然需要我们重启程序来处理异常。后续我们适当扩大了topic的副本数，目前已经处于稳定状态了
