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負載會過重，

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一次
之后即失效，所以需要重新注冊，