【Kafka】4.高可用及Failover流程

写在前面

本文为Kafka系列文章第四篇，全文可见：

• 【Kafka】1.特性与零拷贝
• 【Kafka】2.纯原创，一张图洞悉Kafka集群
• 【Kafka】3.纯原创，消息的发送/存储/消费流程综述
• 【Kafka】4.高可用及Failover流程

Kafka集群高可用逻辑

节点宕机处理流程

故障转移时的操作

Leader发生故障时

1. 会选择ISR中的一个副本，作为新的leader (有可能因为本次选举后，leader集中于某个broker使得集群负载不均衡，此时kafka提供了kafka-preferred-replica-election.sh脚本可以重新进行leader和broker之间的分配)
2. 为了数据一致性，所有的副本+新leader都舍弃HW（High Watermark，即Leader+ISR的最大Offset的最小值）之后的数据，新的数据从HW之后重新开始写入和读取

Follower发生故障时

1. 首先该Follower由于长时间为从Leader拉取消息会被剔出ISR。
2. 由于无法确定在当前follower宕机期间， leader和其他副本之间是否已发生了故障转移导致舍弃了HW之后的数据，所以HW之后的数据是不能直接使用的。当前follower将HW (自己之前记录的HW) 之后的数据舍弃。
3. 从HW的位置重新申请和leader进行同步操作，直到数据追平之后，重新加入ISR中。

Broker Failover流程

普通Broker (非Controller) Failover逻辑

1. Controller会在ZK中注册对于所有集群中的其他Broker的Watch，如果Broker与ZK断开连接，则会收到对应的通知消息 (Watch Fired)
2. Controller收到宕机的通知消息后会查询ZK决定set_p (该broker上所有的，即需要进行故障转移的partition集合)
3. 对于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逻辑

1. 所有的Broker均会在ZK中注册对于Controller的Watch，当Controller与ZK断连，则所有的Broker都会收到消息（Watch Fired）
2. 所有Broker通过竞争的方式在ZK中创建/Controller节点，竞选新的Controller
3. 其他流程与普通Broker一致