内容梗概：
生产者端：使用带回调的API / acks=all / retries=MAX
kafka服务器端：unclean.leader.election.enable=false/ replication.factor >1 / min.insync.replicas >1
消费者端：enable.auto.commit=false（手动提交offset）
笔记正文：
acks=all / retries=MAX]
1. 使用带回调方法的API：
在生产中Kafka生产者的开发我们都会用异步调用的方式，异步调用方式有如下两个API：
producer.send(msg) 不带回调方法
producer.send(msg,callback) 带回调方法
记得要使用带有回调方法的API，我们可以根据回调函数得知消息是否发送成功，如果发送失败了我们要进行异常处理，比如存储到其他介质来保证消息不丢。
2. acks=all
acks ： 指定了必须要有多少个分区副本收到消息，生产者才会认为消息写入时成功的。
acks = 0 ：生产者不会等待任何来自服务器的响应，可以保证数据不重复。
可以以网络能够支持的最大速度发送消息，从而达到很高的吞吐量。
acks = 1 ： 只要集群首领节点收到消息，生产者就会收到一个来自服务器的成功响应。
acks = -1（all） ：只有当所有参与复制的节点全部收到消息时，生产者才会收到一个来自服务器的成功响应。模式最安全，延迟最高。可以保证数据不丢失，但会出现数据重复。
3. retries=MAX
一旦写入失败，就无限重试，卡在这里了，或者设置较大的重试次数（参数是retries），如果重试失败了，对异常进行处理，可以把消息保存到另外安全到地方。
unclean.leader.election.enable=false]
/ replication.factor >1 / min.insync.replicas >1
1. unclean.leader.election.enable = false这个参数是控制leader replica出问题了以后follower replica竞选leader replica资格的，我们把设置为false，意思就是如果follower replica如果落后leader replica太多就不能参与竞选。
2. replication.factor >1
这个参数设置的是partition副本的个数，如果我们要想保证数据不丢，这个副本数需要设置成大于1。
3. min.insync.replicas >1
控制 ISR 最低允许副本数量
ISR（副本同步机制）：每个分区都有自己的一个 ISR 集合，处于 ISR 集合中的副本，意味着 follower 副本与 leader 副本保持同步状态，只有处于 ISR 集合中的副本才有资格被选举为 leader。一条 Kafka 消息，只有被 ISR 中的副本都接收到，才被视为“已同步”状态。这跟 zk 的同步机制不一样，zk 只需要超过半数节点写入，就可被视为已写入成功。
replica.lag.time.max.ms （ISR参数）：该参数的意思指的是允许 follower 副本不同步消息的最大时间值，即只要在 replica.lag.time.max.ms 时间内 follower 有同步消息，即认为该 follower 处于 ISR 中，这就很好地避免了在某个瞬间生产者一下子发送大量消息到 leader 副本导致该分区 ISR 频繁收缩与扩张的问题了。
enable.auto.commit=false（手动提交offset）]
消费者是可以自动提交offset的，但是如果是自动提交offset，可能会丢数据，比如消费者每隔3秒提交一次offset，假如偏移量成功提交了，但是数据处理失败了，这个时候就会丢数据。所以把enable.auto.commit设置成false就行。在处理完之后自己手动提交offset，就可以保证数据不会丢。但是此时确实还是会重复消费，比如你刚处理完，还没提交offset，结果自己挂了，此时肯定会重复消费一次，自己保证幂等性就好了。
内容参考自：
kafka权威指南
