Kafka Partition Leader選舉機制原理詳解（上）

1 大資料常用的選主機制

Leader選舉算法非常多，大資料領域常用的有以下兩種:

1.1 Zab(zookeeper使用)

Zab協定有四個階段

• Leader election
• Discovery (E#epoch establish)
• Synchronization (5X#sync with followers)
• Broadcast

比如3個節點選舉leader：編号為1、2、3。 1先啟動，選擇自己為leader，然後2啟動

首先也選擇自己為leader，由于1,2都沒過半，選擇編号大的為leader，是以1、2都

選擇2為leader，然後3啟動發現1，2已經協商好且數量過半，于是3也選擇2為leader，leader選舉結束。

1.2 Raft

類似美國大選。

在Raft中，任何時候一個伺服器可以扮演下面角色之一：

• Leader

  處理所有用戶端互動，日志複制等，一般隻有一個Leader

• Follower

  類似選民，完全被動

• Candidate候選人

  可被選為一個新的上司人

啟動時在叢集中指定一些機器為Candidate，然後Candidate開始向其他機器(尤

其是Follower)拉票，當某個Candidate的票數超過半數，它就成為leader。

都是 paoxs 算法的變種。

由于Kafka叢集依賴zookeeper叢集，是以最簡單最直覺的方案是，所有Follower

都在ZooKeeper上設定一個Watch，一旦Leader當機，其對應的ephemeral

znode會自動删除，此時所有Follower都嘗試建立該節點，而建立成功者

(ZooKeeper保證隻有一個能建立成功)即是新的Leader，其它Replica即為

Follower。

2 常用選主機制的缺點

2.1 split-brain (腦裂)

這是由ZooKeeper的特性引起的，雖然ZooKeeper能保證所有Watch按順序觸發，但是網絡延遲，并不能保證同一時刻所有Replica“看”到的狀态是一樣的，這就可能造成不同Replica的響應不一緻，可能選出多個上司“大腦”，導緻“腦裂”。

2.2 herd effect (羊群效應)

如果當機的那個Broker上的Partition比較多， 會造成多個Watch被觸發，造成叢集内大量的調整，導緻大量網絡阻塞。

2.3 ZooKeeper負載過重

每個Replica都要為此在ZooKeeper上注冊一個Watch，當叢集規模增加到幾千個Partition時ZooKeeper負載會過重。