kafka节点故障恢复原理

Kafka的LEO和HW

LEO

LEO是Topic每一个副本的最后的偏移量offset+1

HW（高水位线）

High WaterMark是所有副本中，最小的LEO

Follower副本所在节点宕机

由于数据同步的时候数据是先写入Leader，然后Follower副本向Leader同步
只要Leader和其他的Follower副本继续往前存储数据，挂掉的节点在replica.lag.time.max.ms之内没有追上，就会掉出ISR从ISR集合中剔除，如果此时挂掉的Follower又重启了，他会从上次挂掉的时候的HW开始向Follower同步数据，直到追上最新的数据，就会重新回到ISR集合

Leader副本所在节点宕机

(1)情况1：Leader副本宕机时存在同步的Follower副本

如果存在同步Follower副本，此时就保障了在故障时的数据完整性，会被Controller选举为新的Leader副本（如果是多个完全同步的Follower副本，需看谁在ISR集合里靠前），为保证多个副本之间的数据一致性，其余Follower副本会将各自log文件中高于HW的部分截掉，然后从新的Leader副本同步数据；此时宕机的Leader副本重启后会从宕机前的HW开始向新的Leader副本拉取同步数据，直到追上最新的数据，就会回到ISR集合中

（2）情况2：Leader副本宕机时不存在同步的Follower副本

如果不存在同步的Follower副本，此时由Broker的配置来决定unclean.leader.election.enable
unclean.leader.election.enable参数如果设置为false，就是指Leader副本所在的节点宕机时ISR集合里为空，不允许进行Leader副本的副本，如果设置为true表示不存在完整的Follower副本也可以参与Leader副本的选举，这时候会选举出一个新的Leader副本，为保证多个副本之间的数据一致性，其余Follower副本会将各自log文件中高于HW的部分截掉，然后从新的Leader副本同步数据；

注意：这种情况一定会导致数据的丢失，为了保障数据的可靠性和一致性，可以考虑ACK应答机制
相关参数为offsets.commit.required.acks，设置为-1，这是最可靠的模式，则表示在Leader副本和Follower副本都确认成功写入消息后，生产者才会收到确认，缺点是会导致更长的延迟