鱼与熊掌不可兼得，数据也是，想保持高吞吐量就必须牺牲数据完整性，想保证数据完整就必须牺牲高性能，类似例子太多:网络传输协议(TCP/UDP)，数据结构时空效率等等。Kafka做为消息中间件也是如此，如何解决，应该说是尽量避免数据传输中的数据丢失或数据重复？
ACK机制
即producer发送消息确认机制，由参数“request.required.acks"控制，可选值0，1，-1/all。
ack=0时：producer发送请求后不等待leader的返回消息，直接返回commit，即最多一次语义At Most Once
①数据丢失情况：
未发送至leader
follow未复制成功leader数据，leader宕机
ack=1时：producer发送请求后只等待leader的返回
①数据丢失情况：
follow未复制成功leader数据，leader宕机
ack=-1时：数据是由follower复制leader数据后返回成功给leader，producer发送数据后等待leader的返回，leader等待follower返回，即至少一次语义At Least Once
①数据重复情况：
follower复制成功leader数据，leader宕机，生产者未收到leader回复，若判断该leader死亡，将该follower设置为新leader，此条数据由生产者重新发送
②数据丢失情况：
ISR中只有leader一个节点，leader返回成功后leader死亡
ISR是什么？
Kafka维护了一个ISR(In-Sync Replicas)列表，ISR中存放最有可能成功下一任leader的副本+现任leader。当ISR中一个节点响应leader太慢(Kafka-2.5之前为10s，2.5及之后为30s)，该节点被踢出ISR移入OSR，ISR资格在Kafka-0.9版本之前还有一个标准，follower落后leader的消息条数(Kafka-0.9之前是4000条，之后删除此标准)，OSR即ISR之外的副本队列，但是如果ISR中仅有leader且leader死亡时，新leader也会从OSR中选，或者等待OSR中副本进入ISR。
另，leader收集follower返回值有两种方式，①ISR中过半数副本复制完成和②ISR中全部副本复制完成，Kafka用的是后者
| 副本复制完成数 | 出现n个故障时至少需要的副本数 |
| 过半 | 2n+1个 |
| 全部 | n+1个 |
①情况下，出现n个故障时必须保证至少有一个副本时可用的，只有总副本数为n+1时，剩下n+1个副本中至少有一个时过半复制包含的副本，即正常完成复制leader数据的副本
②情况下，因为是ISR全部复制成功，只需要有一个副本，这个副本必是正常副本
HW，LEO
leo，副本offset最大值
hw，所有副本中leo的最小值
有两种情况
①leader故障，选出新leader，新leader此时可能数据量小于原leader(数据复制不完全......)，且数据极有可能是断裂的，这种情况下其余follower将剪裁掉自身offset大于hw的数据，从hw开始复制新leader的数据
②follower故障，被踢出ISR，该follower恢复后会读取本地磁盘记录的上次的old_hw，log高于old_hw的数据全部截掉，再同步leader，当leo大于等于当前hw时，可重新加入ISR
幂等性，事务
Kafka-0.11版本及之后引入了幂等性和事务
幂等性：保证单个producer发送至同一个分区的数据不重复，它会给每个数据分发一格独一无二的sequence(递增)，给每个producer分发一个producerID，写入数据时会校验<PID，partition，sequence>，相同则不能被写入，保证了数据不重复。但是producer重启后PID改变，幂等性失效。要启用幂等性，只需要将producer的参数中"enable.idompotence"设置为true即可。幂等性保证了Exactly Once---仅有一次，公式：
At Least Once(ack=-1，数据不丢失) + 幂等性(数据不重复)=Exactly Once
事务：生产者事务，引入一个全局唯一的TransactionID并将producer获得的PID和TransactionID绑定。这样当producer重启后就可以通过正在进行的TransactionID获得原来的PID。
