leader的選擇方法非常多，大資料領域常用的的選舉方法有如下集中
（1）zab（zookeeper使用）
a、快速leader選舉（leader election）
b、發現或者版本建立（epoch establish）
c、同步（follower從leader同步資料和狀態）
d、廣播（leader廣播資料或狀態到follower）
例如有3個節點需要選舉leader，編號為1，2，3. 先啟動1，選擇自己為leader，然後啟動2，首先也選擇自己為leader。由於1，2都沒有過半，選擇編號大的為leader，所以1，2都選擇2為leader。然後3啟動後發現1，2都已經協商好且數量過半，於是3也選擇2為leader，此時leader選擇結束。（2）raft協議因為zab協議需要選擇過半以上才能被選舉為leader，所以zab協議需要奇數個機器參與選舉（1，3，5，7一般不超過7個，因為zk一般同步元資料，所以負載不是很高，zk管理的節點通訊負載才比較高，5或7個一般能處理大量的集群），一般為第二個節點啟動後被選擇為leader。
相關角色說明
leader：處理所有客戶端互動，日誌複製等，一般只有乙個leader啟動時在集群中指定一些機器為candidate，然後candidate開始向其他機器（尤其是follower）拉票，當某乙個candidate的票數超過半數，它就成為leader（同美國**選舉）。follower：類似選民，完全被動
candidate：候選人，可以為選為乙個新的領導，由管理員配置
兩種選擇演算法的區別聯絡
（1）他們都是paxos演算法的變種。
（2）與zab協議不同的是，zab的每乙個節點都有被選為leader的協議，raft協議必須從候選人中選擇為leader。
最簡單的方式
由於kafka集群依賴zookeeper集群，所以最簡單直觀的方案是：所有的follower都在zookeeper上設定乙個watch，一旦leader宕機，其對應的ephemeral znode（臨時節點）會自動刪除，此時所有follower都嘗試建立該節點，而建立成功者（zookeeper保證只有乙個能建立成功）即是新的leader，其他replica即為follower。
該方式有如下缺點：
a、腦裂（split-brain）
這是由於zookeeper的特性引起的，雖然zookeeper能保證所有的watch按順序觸發，但並不能保證同一時刻所有的replica看到的狀態是一樣的，這就可能造成不同的replica的響應不一致；（如由於網路原因部分選擇的leader已經更新，但是其他follower由於網路原因沒有看到，部分又選舉出乙個leader，導致乙個集群出現兩個leader）b、羊（驚）群效應（herd effect）
如果宕機的哪個broker上的partition比較多，會造成多個watch被觸發，造成集群類大量的調整（向羊群開一槍所有羊群四處奔散，造成網路資源和負載）。kafka如何解決以上選舉機制的c、zookeeper負載過重：每乙個replica都要為此在zookeeper上註冊乙個watch，當集群規模增加到幾千個partition時，zookeeper負載會過重。
kafka的leader election方案解決了上述問題，它在所有的broker中選出乙個controller，所有的partition的leader選舉都有controller決定。controller會將leader的改變直接通過rpc的方式（比zookeeper queue的方式更高效）通知需要為此作為響應的broker。
原因：
1、不用zk選舉，使用controller（controller會將leader的改變通過rpc方式通知給follower），沒有zk負載過重問題
2、也沒有註冊watch不會觸發任何事件-驚群效應
3、leader失敗是由乙個controller進行選舉並不會產生任何通訊，所以不會有腦裂的情況
問題：
（1）controller是如何選舉出來的
每乙個broker都會在controller path（/controller）上註冊乙個watch。當前controller失敗時，對應的controller path會自動消失（臨時節點）。此時該watch被觸發，所有活著的broker都會去競選成為新的controller（建立新的controller path），但是只有乙個會競選成功。競選成功者成為新的leader。競選失敗則重新在新的controller path上註冊watch，因為zk的watch是一次性的，被觸發一次之後即失效，所以需要重新註冊。
（2）如何使用controller進行partition選舉
a、從zk中讀取當前分割槽的所有isr（in-sync-replicas）集合
b、呼叫配置的分割槽演算法選擇分割槽的leader
kafka選擇分割槽演算法：
i、noopleaderselector–偏愛分割槽（sr中的第乙個），並將leader傳送給為此做出改變的broker，
ii、offlinepartitionleader–也是選擇偏愛分割槽作為leader
iii、reassignedpartitionleader
iii、preferredreplicapartitionleader
iiii、controlledshutdownleader
上面五中演算法都使用偏愛分割槽作為leader，區別是選擇leader之後所做的操作不同。
ES的選主機制
es集群中必須 有且只有乙個master節點，如果出現了兩個master節點 腦裂問題 那麼就出問題了，由哪乙個master節點來管理集群呢，傻傻的分不清楚，是不！那麼怎樣來進行master的選舉呢？主要根據以下三個方面來進行es的選舉 對有資格成為master的節點進行nodeid排序，每一次選舉...
kafka分割槽和副本機制驗證
目前使用kafka集群，但是由於資料量還行，就不想使用太多的分割槽，所以只想弄乙個分割槽，網上資料看了一大堆，基本都是些理論和囉嗦，於是乎自己手動來驗證下這個情況的好壞。假設是三颱機器的kafka集群，建立乙個主題one fb1 fq1，指定副本數1和分割槽數1，命令 bin kafka topic...
zookeeper的選主機制的實現過程以及原理
zookeeper是乙個分布式的，開放原始碼的分布式應用程式協調服務，它包含乙個簡單的原語集，分布式式應用程式可以基於它實現同步服務，配置維護和命名服務等。zookeeper是hadoop的乙個子專案。在分布式應用中，由於部分開發者不能很好的使用鎖機制，以及基於訊息的協調機制不適合在某些應用中使用，...