寫在前面
本文為Kafka系列文章第四篇捌年，全文可見：
- 【Kafka】1.特性與零拷貝
- 【Kafka】2.純原創(chuàng)，一張圖洞悉Kafka集群
- 【Kafka】3.純原創(chuàng)片吊，消息的發(fā)送/存儲/消費流程綜述
- 【Kafka】4.高可用及Failover流程
Kafka集群高可用邏輯
節(jié)點宕機處理流程
<Topic/Partition>故障轉(zhuǎn)移時的操作
Leader發(fā)生故障時
- 會選擇ISR中的一個副本佩谣，作為新的leader (有可能因為本次選舉后把还，leader集中于某個broker使得集群負(fù)載不均衡，此時kafka提供了kafka-preferred-replica-election.sh腳本可以重新進(jìn)行l(wèi)eader和broker之間的分配)
- 為了數(shù)據(jù)一致性茸俭，所有的副本+新leader都舍棄HW（High Watermark吊履，即Leader+ISR的最大Offset的最小值）之后的數(shù)據(jù)，新的數(shù)據(jù)從HW之后重新開始寫入和讀取
Follower發(fā)生故障時
- 首先該Follower由于長時間為從Leader拉取消息會被剔出ISR调鬓。
- 由于無法確定在當(dāng)前follower宕機期間艇炎， leader和其他副本之間是否已發(fā)生了故障轉(zhuǎn)移導(dǎo)致舍棄了HW之后的數(shù)據(jù)，所以HW之后的數(shù)據(jù)是不能直接使用的腾窝。當(dāng)前follower將HW (自己之前記錄的HW) 之后的數(shù)據(jù)舍棄缀踪。
- 從HW的位置重新申請和leader進(jìn)行同步操作，直到數(shù)據(jù)追平之后虹脯，重新加入ISR中驴娃。
Broker Failover流程
普通Broker (非Controller) Failover邏輯
- Controller會在ZK中注冊對于所有集群中的其他Broker的Watch，如果Broker與ZK斷開連接循集，則會收到對應(yīng)的通知消息 (Watch Fired)
- Controller收到宕機的通知消息后會查詢ZK決定set_p (該broker上所有的<topic唇敞， partition， leader>暇榴，即需要進(jìn)行故障轉(zhuǎn)移的partition集合)
- 對于set_p中的partition
- (a) 查詢ZK上的/brokers/topics/[topic]/partitions/[partition]/state厚棵，得到ISR信息*
- (b) 從ISR中選出新的leader蕉世，如果當(dāng)前ISR為空時也可以從AR (assigned replicas蔼紧，即全量副本)中選擇 (unclean. leader.election.enable=默認(rèn)為true)，可能有HW以下數(shù)據(jù)損失的風(fēng)險*
- (c) 將新的leader和對應(yīng)的ISR信息回寫ZK上的/brokers/topics/[topic]/partitions/[partition]/state中*
- (d) 通過RPC調(diào)用告知 follower promotion相關(guān)的Broker狠轻，變更其中這部分replica的角色*
Controller Failover邏輯
- 所有的Broker均會在ZK中注冊對于Controller的Watch奸例，當(dāng)Controller與ZK斷連，則所有的Broker都會收到消息（Watch Fired）
- 所有Broker通過競爭的方式在ZK中創(chuàng)建/Controller節(jié)點，競選新的Controller
- 其他流程與普通Broker一致
