zookeeper選舉機制

1、概述

　　1. 第一個階段：數據恢復階段

 　　每個主機（節點）在啓動以後，都會先查找當前主機（節點）中最大事務id

 　　2. 第二個階段：選舉階段

　　剛開始的時候，每個節點都會選舉本身當leader，而且將本身的選舉信息發送給其餘節點，和其餘節點進行比較。通過多輪比較以後，會選出一個節點成爲leader

2、細節
 　　1. 選舉信息：
 　　　　 a. 最大事務id
　　　　  b. 選舉編號 - myid
 　　　　 c. 邏輯時鐘值 - 用於控制全部的節點處在同一輪選舉上
 　　2. 比較過程：
　　　　  a. 先比較兩個節點之間的最大事務id，誰的最大事務id大誰就勝出
  　　　　b. 若是事務id一致，則比較myid。誰的myid大誰就勝出
 　　　　 c. 若是一個節點贏過一半及以上的節點，那麼這個節點就會成爲leader - 選舉的過半性
 　　3. 若是leader產生宕機，那麼剩餘的Zookeeper節點會自動選舉出一個新的leader，所以在Zookeeper中不存在單點故障
 　　4. 若是在集羣中由於分裂而致使出現多個leader的現象稱之爲腦裂
 　　5. 在Zookeeper中，若是存活的節點數量不足整個集羣中節點的數量的一半，那麼這個時候Zookeeper集羣再也不選舉也不對外提供服務 - 所以集羣的節點個數通常也是奇數個
 　　6. Zookeeper會對每一次選出的leader分配一個全局的遞增編號 - epochid。若是集羣中出現了多個leader，那麼Zookeeper就會kill掉epochid相對較小的leader
 　　7. 節點狀態變化：
  　　　　a. looking/voting：選舉狀態
　　　　  b. follower：追隨者
 　　　　 c. leader：領導者
 　　　　 d. observer：觀察者
 　　8. 若是整個集羣中已經存在leader，那麼新添加的節點的事務id和myid不管是多少都只能成爲follower

3、觀察者 　　1. 觀察者的特色：既不參與投票也不參與選舉，可是監聽投票和選舉結果，而後根據結果來執行任務 　　2. 適用場景：集羣節點數量多的時候能夠將一部分節點設置爲觀察者；網絡條件不穩定的狀況下，能夠將部分節點設置爲觀察者 　　3. observer的存活與否並不影響集羣是否對外服務。例如一個集羣中有21個節點，其中14個節點是observer，那麼即便這14個observer節點所有宕機，該集羣也會正常對外提供服務，可是若是有4個follower節點宕機，則即便全部的observer都存活該集羣也不對外提供服務