1. 副本数据同步策略

两种副本数据同步策略（Kafka选择第二种）

方案	优点	缺点
半数以上完成同步，就发送ack	延迟低	选举新的leader时，容忍n台节点的故障，需要2n+1个副本
全部完成同步，才发送ack	选举新的leader时，容忍n台节点的故障，需要n+1个副本	延迟高

Kafka选择了第二种方案，原因如下：

为了容忍n台节点的故障，第一种方案需要2n+1个副本，而第二种方案只需要n+1个副本，而Kafka的每个分区都有大量的数据，第一种方案会造成大量数据的冗余。虽然第二种方案的网络延迟会比较高，但网络延迟对Kafka的影响较小。

2. ISR

为了防止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发生故障，就会从ISR中选举新的leader。

说白了就是一个衡量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，就会进行下一轮的发送，否则重新发送数据。

Kafka的数据可靠性保证
Kafka的数据可靠性保证
1. 副本数据同步策略
2. ISR
3. ack应答机制
4. 故障处理

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，不影响。

Kafka的数据可靠性保证
Kafka的数据可靠性保证
1. 副本数据同步策略
2. ISR
3. ack应答机制
4. 故障处理

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同步数据。

注意：这只能保证副本之间的数据一致性，并不能保证数据不丢失或者不重复。（是否丢数据是acks保证）