kafka针对数据丢失和数据重复数据乱序的问题，的配置列表

引自：https://www.cnblogs.com/cherish010/p/9764810.html

鉴于producer的数据丢失和数据乱序两个问题，我们应该如何规避呢？对于消息丢失的问题，很容易想到的一个方法就是:既然异步发送有可能丢失数据，我改成同步发送总可以吧？比如这样：
producer.send(record).get();

这样当然是可以的，但是性能会很差，不建议这样使用，因此特意总结了一份配置列表，个人认为该配置清单应该能够比较好的规避producer端数据丢失情况的发生:(但说明一下，软件配置的很多决策都是trade-off，下面的配置也不例外：应用了这些配置，你可能会发现你的producer/consumer吞吐量会下降，这是正常的，因为你换取了更高的数据安全性)

 

block.on.buffer.full = true 尽管该参数在0.9.0已经被标识为“deprecated”,但鉴于它的含义非常直观，所以这里还是显式设置它为true，使得producer将一直等待缓冲区直至其变为可用，否则如果producer生产速度过快耗尽了缓冲区，producer将抛出异常，缓冲区满了就阻塞在那，不要抛异常，也不要丢失数据。

acks =all 所有的folloer都相应了才认为消息提交成功，即“committed”

retried = Max 无限重试，直到你意识到出现了问题

max.in.flight.requests.per.connection = 1限制客户端在单个连接上能够发送的未响应请求的个数，设置此值是1 表示kafka broker在响应请求之前client不能再向同一个broker发送请求，注意:设置此参数是为了避免消息乱序

使用KafkaProducer.send(record,callback)而不是send(record)方法，自定义回调逻辑处理消息发送失败，比如记录在日志中，用定时脚本扫描重处理callback逻辑中最好显示关闭producer，close(0)注意：设置此参数是为了避免消息乱序（仅仅因为一条消息发送没收到反馈就关闭生产者，感觉代价很大）

unclean.leader.election.enable = false 关闭unclean leader选举，即不允许非ISR中的副本被选举为leader，以避免数据丢失

replication.factor>=3 这个完全是个人建议，参考了hadoop及业界通用的三备份原则

min.insync.replicas > 1消息至少要被写入到这么多副本才算成功，也是提升数据持久性的一个参数，与acks配合使用保证replication.factor>min.insync.replicas 如果两者相等，当一个副本挂掉了分区也就没法正常工作了，通常设置replication.factor = min.insync,replicas + 1即可。

2、Consumer端

     consumer端丢失消息的情形比较简单：如果在消息处理完成前就提交了offset，那么就有可能造成数据的丢失，由于kafka consumer默认是自动提交位移的，所以在后台提交位移前一定要保证消息被正常处理了，因此不建议采用很重的处理逻辑，如果处理耗时很长，则建议把逻辑放到另一个线程中取做，为了避免数据丢失，现给出两点建议:

enable.auto.commit = false 关闭自动提交位移