一、概述
大數據常用的選主機制
常用選主機制的缺點
Kafka Partition選主機制
二、大數據常用的選主機制
Leader選舉算法非常多，大數據領域常用的有 以下兩種:
Zab(zookeeper使用);
Raft； ……
它們都是Paxos算法的變種。
Zab協議有四個階段:
Leader election;
Discovery（或者epoch establish）；
Synchronization（或者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選舉結束。
在Raft中，任何時候一個服務器可以扮演下面角色之一
Leader: 處理所有客戶端交互，日志復制等，一般只有一個Leader；
Follower: 類似選民，完全被動
Candidate候選人: 可以被選為一個新的領導人
啟動時在集群中指定一些機器為Candidate ，然后Candidate開始向其他機器(尤其是Follower)拉票，當某一個Candidate的票數超過半數，它就成為leader。
常用選主機制的缺點
由於Kafka集群依賴zookeeper集群，所以最簡單最直觀的方案·是，所有Follower都在ZooKeeper上設置一個Watch，一旦Leader宕機，其對應的ephemeral znode會自動刪除，此時所有Follower都嘗試創建該節點，而創建成功者（ZooKeeper保證只有一個能創建成功）即是新的Leader，其它Replica即為Follower。
前面的方案有以下缺點：
split-brain (腦裂): 這是由ZooKeeper的特性引起的，雖然ZooKeeper能保證所有Watch按順序觸發，但並不能保證同一時刻所有Replica“看”到的狀態是一樣的，這就可能造成不同Replica的響應不一致 ;
herd effect (羊群效應): 如果宕機的那個Broker上的Partition比較多，會造成多個Watch被觸發，造成集群內大量的調整；
ZooKeeper負載過重 : 每個Replica都要為此在ZooKeeper上注冊一個Watch，當集群規模增加到幾千個Partition時ZooKeeper負載會過重
三、Kafka Partition選主機制
Kafka 的Leader Election方案解決了上述問題，它在所有broker中選出一個controller，所有Partition的Leader選舉都由controller決定。controller會將Leader的改變直接通過RPC的方式（比ZooKeeper Queue的方式更高效）通知需為此作為響應的Broker。
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一次之后即失效，所以需要重新注冊。
Kafka partition leader的選舉過程如下 (由controller執行)：
從Zookeeper中讀取當前分區的所有ISR(in-sync replicas)集合
調用配置的分區選擇算法選擇分區的leader