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

3 Kafka Partition選主機制

3.1 優勢

Kafka的Leader Election方案解決了上述問題，它在所有broker中選出一個controller，所有Partition的Leader選舉都由controller決定。

controller會将Leader的改變直接通過RPC的方式(比ZooKeeper Queue的方式更高效)通知需為此作為響應的Broker。

沒有使用 zk，是以無 2.3 問題；也沒有注冊 watch無 2.2 問題

leader 失敗了，就通過 controller 繼續重新選舉即可，是以克服所有問題。

3.2 Kafka叢集controller的選舉

每個Broker都會在Controller Path (/controller)上注冊一個Watch。 目前

Controller失敗時，對應的Controller Path會自動消失(因為它是ephemeral

Node)，此時該Watch被fire，所有“活” 着的Broker都會去競選成為新的

Controller (建立新的Controller Path)，但是隻會有一個競選成功(這點由

Zookeeper保證)。競選成功者即為新的Leader，競選失敗者則重新在新的

Controller Path上注冊Watch。因為Zookeeper的Watch是一次性的， 被fire一次

之後即失效，是以需要重新注冊。

3.3 Kafka partition leader的選舉

由controller執行：

• 從Zookeeper中讀取目前分區的所有ISR(in-sync replicas)集合
• 調用配置的分區選擇算法選擇分區的leader

• 

• 上面五種分區算法都是選擇PreferredReplica作為目前Partition的leader。差別僅

僅是選擇leader之後的操作有所不同。

是以，對于下圖partition 0先選擇broker2，之後選擇broker 0作カleader；對于

partition 1先選擇broker 0，之後疊拝broker 1作カleader；partition 2先選擇

broker1，之後選擇 broker2作為leader。