Zookeeper選舉原理
Zookeeper選舉原理
作為一個分布式應用程序協調服務，在大型網站中，其本身也是集群部署的，安裝zookeeper的時候最好是單數節點，因為要選舉。Zookeeper的leader節點是集群工作的核心，用來更新並保證leader和server具有相同的系統狀態，Follower服務器是Leader的跟隨者，用於接收客戶端的請求並向客戶端返回結果，在選舉過程中參與投票。對於客戶端來說，每個zookeeper都是一樣的。
zookeeper提供了三種選擇策略：
- LeaderElection
- AuthFastLeaderElection
- FastLeaderElection
這裏僅介紹默認的算法：FastLeaderElection。
基礎概念
- Sid：服務器id；
- Zxid：服務器的事務id，數據越新，zxid越大；
- epoch：邏輯時鐘，在服務端是一個自增序列，每次進入下一輪投票後，就會加1；
- server狀態：
- Looking（選舉狀態）
- Leading（領導者狀態，表明當前server是leader）
- Following（跟隨者狀態，表明當前server是Follower）
- Observing（觀察者狀態、表明當前server是Observer）。
選舉步驟
當系統啟動或者leader崩潰後，就會開始leader的選舉。
狀態變更。服務器啟動的時候每個server的狀態時Looking，如果是leader掛掉後進入選舉，那麽余下的非Observer的Server就會將自己的服務器狀態變更為Looking，然後開始進入Leader的選舉狀態；
發起投票。每個server會產生一個（sid，zxid）的投票，系統初始化的時候zxid都是0，如果是運行期間，每個server的zxid可能都不同，這取決於最後一次更新的數據。將投票發送給集群中的所有機器；
接收並檢查投票。server收到投票後，會先檢查是否是本輪投票，是否來自looking狀態的server；
處理投票。對自己的投票和接收到的投票進行PK：
- 先檢查zxid，較大的優先為leader；
如果zxid一樣，sid較大的為leader；
根據PK結果更新自己的投票，在次發送自己的投票；
統計投票。每次投票後，服務器統計投票信息，如果有過半機器接收到相同的投票，那麽leader產生，如果否，那麽進行下一輪投票；
改變server狀態。一旦確定了Leader，server會更新自己的狀態為Following或者是Leading。選舉結束。
補充說明：
在步驟2發送投票的時候，投票的信息除了sid和zxid，還有：
- electionEpoch：邏輯時鐘，用來判斷多個投票是否在同一輪選舉周期中，該值在服務端是一個自增序列，每次進入新一輪的投票後，都會對該值進行加1操作。
- peerEpoch：被推舉的Leader的epoch。
- state：當前服務器的狀態。
為了能夠相互投票，每兩臺服務器之間都會建立網絡連接，為避免重復建立TCP連接，zk的server只允許sid大於自己的服務器與自己建立連接，否則斷開當前連接，並主動和對方建立連接。
參考：
https://www.cnblogs.com/felixzh/p/5869212.html
https://www.cnblogs.com/leesf456/p/6107600.html
https://www.cnblogs.com/ASPNET2008/p/6421571.html
Zookeeper選舉原理