写在前面
本文为Kafka系列文章第四篇，全文可见：
Kafka集群高可用逻辑
节点宕机处理流程
<Topic/Partition>故障转移时的操作
Leader发生故障时
- 会选择ISR中的一个副本，作为新的leader (有可能因为本次选举后，leader集中于某个broker使得集群负载不均衡，此时kafka提供了kafka-preferred-replica-election.sh脚本可以重新进行leader和broker之间的分配)
- 为了数据一致性，所有的副本+新leader都舍弃HW（High Watermark，即Leader+ISR的最大Offset的最小值）之后的数据，新的数据从HW之后重新开始写入和读取
Follower发生故障时
- 首先该Follower由于长时间为从Leader拉取消息会被剔出ISR。
- 由于无法确定在当前follower宕机期间， leader和其他副本之间是否已发生了故障转移导致舍弃了HW之后的数据，所以HW之后的数据是不能直接使用的。当前follower将HW (自己之前记录的HW) 之后的数据舍弃。
- 从HW的位置重新申请和leader进行同步操作，直到数据追平之后，重新加入ISR中。
Broker Failover流程
普通Broker (非Controller) Failover逻辑
- Controller会在ZK中注册对于所有集群中的其他Broker的Watch，如果Broker与ZK断开连接，则会收到对应的通知消息 (Watch Fired)
- Controller收到宕机的通知消息后会查询ZK决定set_p (该broker上所有的<topic， partition， leader>，即需要进行故障转移的partition集合)
- 对于set_p中的partition
- (a) 查询ZK上的/brokers/topics/[topic]/partitions/[partition]/state，得到ISR信息*
- (b) 从ISR中选出新的leader，如果当前ISR为空时也可以从AR (assigned replicas，即全量副本)中选择 (unclean. leader.election.enable=默认为true)，可能有HW以下数据损失的风险*
- (c) 将新的leader和对应的ISR信息回写ZK上的/brokers/topics/[topic]/partitions/[partition]/state中*
- (d) 通过RPC调用告知 follower promotion相关的Broker，变更其中这部分replica的角色*
Controller Failover逻辑
- 所有的Broker均会在ZK中注册对于Controller的Watch，当Controller与ZK断连，则所有的Broker都会收到消息（Watch Fired）
- 所有Broker通过竞争的方式在ZK中创建/Controller节点，竞选新的Controller
- 其他流程与普通Broker一致
