为保证 producer 发送的数据，能可靠的发送到指定的 topic，topic 的每个 partition 收到 producer 发送的数据后，都需要向 producer 发送 ack(acknowledgement 确认收到)，如果 producer 收到 ack，就会进行下一轮的发送，否则重新发送数据。
1)副本数据同步策略
|
方案 |
优点 |
缺点 |
|
半数以上完成同步，就发 送 ack |
延迟低 |
选举新的 leader 时，容忍 n 台 节点的故障，需要 2n+1 个副 本(N+1台同步完成) |
|
全部完成同步，才发送 ack |
选举新的 leader 时，容忍 n 台 节点的故障，需要 n+1 个副 本 |
延迟高（N+1台同步完成） |
Kafka 选择了第二种方案，原因如下:
1.同样为了容忍 n 台节点的故障，第一种方案需要 2n+1 个副本，而第二种方案只需要 n+1
个副本，而 Kafka 的每个分区都有大量的数据，第一种方案会造成大量数据的冗余。
2.虽然第二种方案的网络延迟会比较高，但网络延迟对 Kafka 的影响较小。
存在的问题：如果有10个副本。有一个挂了，那么永远都不会有ack发送回去。
kafak做了一个优化：
ISR（同步副本）：消息条数差值replica.lag.time.max.messages/通信时间长短(同步时间replica.lag.time.max.ms) 两个条件来选副本进ISR， 高版本中不再关注副本的消息条数最大条件。 新版本：如果副本同步时间超过replica.lag.time.max.ms（默认10s），follower就会被移出ISR.
采用第二种方案之后，设想以下情景:leader 收到数据，所有 follower 都开始同步数据， 但有一个 follower，因为某种故障，迟迟不能与 leader 进行同步，那 leader 就要一直等下去， 直到它完成同步，才能发送 ack。这个问题怎么解决呢?
Leader 维护了一个动态的 in-sync replica set (ISR)，意为和 leader 保持同步的 follower 集 合。
当 ISR 中的 follower 完成数据的同步之后，leader 就会给 follower 发送 ack。如果 follower 长时间未向 leader 同步数据，则该 follower 将被踢出 ISR，该时间阈值由
replica.lag.time.max.ms 参数设定。Leader 发生故障之后，就会从 ISR （同步副本）中选举新的 leader。
为何会去掉消息条数差值参数？
因为kafka一般是按batch批量发数据到leader, 如果批量条数12条，replica.lag.time.max.messages参数设置是10条（默认10000条），那么当一个批次消息发到kafka leader，此时，ISR中就要踢掉所有的follower,很快follower同步完所有数据后，follower又要被加入到ISR，频繁操作。