Zookeeper之Leader選舉過程
阿新 • • 發佈：2019-09-04
Leader在叢集中是一個非常重要的角色，負責了整個事務的處理和排程，保證分散式資料一致性的關鍵所在。既然Leader在ZooKeeper叢集中這麼重要所以一定要保證叢集在任何時候都有且僅有一個Leader存在。
概念
Zookeeper Server三種角色：Leader，Follower，Observer。
Leader是Zookeeper 叢集工作機制的核心，主要工作：
- a.排程者：叢集內部各個服務節點的排程者
- b.事務請求：事務請求的唯一排程和處理者，保證叢集事務處理的順序性
Follower主要職責：
- a.非事務請求：Follower 直接處理非事務請求，對於事務請求，轉發給 Leader
- b.Proposal 投票：Leader 上執行事務時，需要 Follower 投票，Leader 才真正執行
- c.Leader 選舉投票
Observer主要職責：
- a.非事務請求：Follower 直接處理非事務請求，對於事務請求，轉發給 Leader
Observer 跟 Follower的區別：
- a.Follower 參與投票：Leader 選舉、Proposal 提議投票（事務執行確認）
- b.Observer 不參與投票：只用於提供非事務請求的處理
Zookeeper Server的狀態
- LOOKING：尋找Leader
- LEADING：Leader狀態，對應的節點為Leader。
- FOLLOWING：Follower狀態，對應的節點為Follower。
- OBSERVING：Observer狀態，對應節點為Observer，該節點不參與Leader選舉。
其它概念
- ZXID（zookeeper transaction id）：每個改變Zookeeper狀態的操作都會形成一個對應的zxid，並記錄到transaction log中。 這個值越大，表示更新越新
- myid：伺服器SID，一個數字,通過配置檔案配置，唯一
- SID：伺服器的唯一標識
- 成為Leader的必要條件： Leader要具有最高的zxid；當叢集的規模是n時，叢集中大多數的機器（至少n/2+1）得到響應並follow選出的Leader。
- 心跳機制：Leader與Follower利用PING來感知對方的是否存活，當Leader無法相應PING時，將重新發起Leader選舉。
選舉有兩種情況，一是伺服器啟動的投票，二是執行期間的投票。
伺服器啟動時期的Leader選舉
1.每個伺服器傳送一個投票(SID,ZXID)
其中sid是自己的myid，初始階段都將自己投為Leader。
2.接收來自其他伺服器的投票。
叢集的每個伺服器收到投票後，首先判斷該投票的有效性，如檢查是否是本輪投票、是否來自LOOKING狀態的伺服器。
3.處理投票
針對每個投票都按以下規則與自己的投票PK，PK後依據情況是否更新投票，再發送給其他機器。
- a.優先檢查ZXID，ZXID較大者優先為Leader
- b.如果ZXID相同，檢查SID，SID較大者優先為Leader
5.統計投票
每次投票後，伺服器統計所有投票，判斷是否有過半的機器收到相同的投票，如果某個投票達到一半的要求，則認為該投票提出者可以成為Leader。
6.改變伺服器狀態
一旦確定了Leader，每個伺服器都更新自己的狀態，Leader變更為Leading，Follower變更為Following
正常情況下一旦選出一個Leader則一直會保持，除非Leader伺服器宕掉，則再進行重新選舉。
伺服器執行時期的Leader選舉
1.變更狀態
當Leader宕機後，餘下的所非Observer的伺服器都會將自己的狀態變更為Looking，然後開啟新的Leader選舉流程。
2.每個伺服器發出一個投票。
生成(SID,ZXID)資訊，注意執行期間的ZXID可能是不同的，但是在投票時都會將自己投為Leader，然後傳送給其他的伺服器。
3.接收來自各個伺服器的投票
與啟動時過程相同
4.處理投票
與啟動時過程相同
5.統計投票
與啟動時過程相同
6.改變伺服器狀態
與啟動時過程相同
資料
- Java問題收集
- ZooKeeper 技術內幕：Leader 選舉