副本数据同步策略
ISR机制
ack应答机制
故障处理：HW、LEO
两种副本数据同步策略（Kafka选择第二种）
| 方案 | 优点 | 缺点 |
|---|---|---|
| 半数以上完成同步，就发送ack | 延迟低 | 选举新的leader时，容忍n台节点的故障，需要2n+1个副本 |
| 全部完成同步，才发送ack | 选举新的leader时，容忍n台节点的故障，需要n+1个副本 | 延迟高 |
Kafka选择了第二种方案，原因如下：
为了容忍n台节点的故障，第一种方案需要2n+1个副本，而第二种方案只需要n+1个副本，而Kafka的每个分区都有大量的数据，第一种方案会造成大量数据的冗余。 虽然第二种方案的网络延迟会比较高，但网络延迟对Kafka的影响较小。
为了防止Kafka在选择第二种数据同步策略时，因为某一个follower故障导致leader一直等下去，Leader维护了一个动态的in-sync replica set (ISR)。
ISR：同步副本，和leader保持同步的follower集合。当ISR中的follower完成数据的同步之后，leader就会给生产者发送ack。 特殊情况：
允许 follower 副本落后 leader 副本的消息数量，超过这个数量后，follower 会被踢出 IS，该数量阈值由replica.lag.max.messages参数
如果follower长时间未向leader同步数据，则该follower将被踢出ISR，该时间阈值由replica.lag.time.max.ms参数设定（默认：10s）。
说白了就是一个衡量leader和follower之间差距的标准。
一个是基于时间间隔，一个是基于消息条数。
为什么?
因为producer是可以批量发送消息的，很容易超过replica.lag.max.messages，那么被踢出ISR的follower就是受了无妄之灾。
他们都是没问题的，既没有出故障也没高延迟，凭什么被踢？
replica.lag.max.messages调大呢？调多大？太大了是否会有漏网之鱼，造成数据丢失风险？
这就是replica.lag.max.messages的设计缺陷。
为保证producer发送的数据，能可靠的发送到指定的topic，topic的每个partition收到producer发送的数据后，都需要向producer发送ack（acknowledgement确认收到），如果producer收到ack，就会进行下一轮的发送，否则重新发送数据。
acks=0 producer不等待broker的ack，broker一接收到还没有写入磁盘就已经返回。 当broker故障时，有可能丢失数据。
acks=1 producer等待broker的ack，partition的leader落盘成功后返回ack。 如果在follower同步成功之前leader故障，那么将会丢失数据。
acks=-1(all) producer等待broker的ack，partition的leader和follower（ISR中的所有follower）全部落盘成功后才返回ack。 如果在follower同步完成后，broker发送ack之前leader发生故障，此时kafka从ISR中重新选举一个leader，生产者没有收到ack重新发送一份到新leader上，则造成数据重复。 如果ISR中只剩一个leader时，此时leader发生故障，可能会造成数据丢失。 如果一个follower故障，该节点被踢出ISR，只要ISR中所有节点都同步即可返回ack，不影响。
LEO：指的是每个副本最大的*offset；
HW：指的是消费者能见到的最大的 offset，ISR 队列中最小的LEO。
follower 发生故障后会被临时踢出 ISR，待该 follower 恢复后，follower 会读取本地磁盘
记录的上次的 HW，并将 log 文件高于 HW 的部分截取掉，从 HW 开始向 leader 进行同步。
等该 follower 的 LEO 大于等于该 Partition 的 HW，即 follower 追上 leader 之后，就可以重
新加入 ISR 了。
leader 发生故障之后，会从 ISR 中选出一个新的 leader，之后，为保证多个副本之间的数据一致性，其余的 follower 会先将各自的 log 文件高于 HW 的部分截掉，然后从新的 leader同步数据。
注意：这只能保证副本之间的数据一致性，并不能保证数据不丢失或者不重复。
原文：https://www.cnblogs.com/shangwei/p/14822230.html