Zookeeper—Leader選舉

Leader選舉

概述

在Zookeeper集羣正常運行期間，一旦選舉出Leader，所有服務器的集羣狀態一般不會發生改變，即使是新機器加入、非Leader機器掛了，也不會影響Leader。但是一旦Leader掛了，那麼整個集羣將暫時無法對外服務，而是進入新的一輪Leader選舉。服務器運行期間的Leader選舉和服務器啓動期間的Leader選舉基本過程是一致的。

在服務器啓動期間，如果超過2臺機器啓動了，那麼這些機器會嘗試去選舉出一個Leader。Leader用於處理客戶端請求。

Leader選舉的隱式條件是至少要有2臺服務器。

服務器啓動時期的Leader選舉

下面我們假設當前有Server1、Server2、Server3 三臺機器爲例子。在服務器集羣初始化節點，有一臺機器（假設這臺機器myId=1，我們稱他爲Server1）啓動的時候，那麼1臺機器是無法進行選舉的。當第二臺機器（myId=2，稱爲Server2）啓動的時候，兩臺機器試圖找出一個Leader，因此進入Leader選舉流程，如下：

• 每個Server發出一個投票
  • 每次投票包含的最基本元素，包括：服務器本身的myId和ZXID。我們以（myId，ZXID）來表示。
  • 初始情況，每個服務器都會投自己一票。即Service1的投票爲（1，0），Server2的投票爲（2，0）。
  • 然後Server1、Server2將各自的投票發給集羣中其他機器
• 接收來自各個服務器的投票
  • 每個服務器都會接收來自其他服務器的投票。
  • 在接收到投票的時候，先判斷該投票的有效性，包括檢查是否本輪投票、是否來自LOOKING狀態的服務器。
• 處理投票
  • 服務器需要將別人的投票和自己的投票進行PK。PK規則如下：
    • 優先檢查ZXID。ZXID比較大的服務器優先作爲Leader
    • 如果ZXID相同，則比較myId，myId比較大的服務器作爲Leader服務器
  • 對於Server1來說，它的投票是（1，0），而接收到的投票是（2，0）。根據上述規則，Server2的投票勝出。
  • 由於Server2投票勝出，Server1將自己的投票更新爲（2，0），然後重新將投票發出去
  • 對於Server2來說，不需要更新自己的投票信息，只需要再一次向集羣中發出上次的投票信息即可。
• 統計投票
  • 每次投票後，服務器都會統計是否有過半機器收到相同的投票。對於Server1和Server2來說，都統計出集羣中已經有2臺機器接受了（2，0）這個投票信息。即認爲已經選舉出Leader了（Server2爲Leader）
• 改變服務器狀態
  • 一旦確定了Leader，每臺服務器都將更新自己的狀態。如果是Follower，那麼就變更爲FOLLOWING狀態；如果是Leader，則更新爲LEADING狀態。

服務器運行時期的Leader選舉

我們假設正在運行的Zookeeper集羣由3臺機器組成，分別爲Server1、Server2、Server3。當前Leader是Server2。假設某一瞬間，Leader掛了，那麼開始Leader選舉：

• 變更狀態：
  • 所有的機器狀態變更爲LOOKING（尋找Leader狀態），然後開始進入Leader選舉流程
• 每個Server會發出一個投票
  • 每個Server會生成一個投票，投票信息爲（myId，ZXID）。因爲是運行時，所以每臺服務器上的ZXID可能不同，我們假定Server1的ZXID爲123，Server3的ZXID爲122。
  • 在第一輪投票中，每個Server都會投票給自己，即Server1產生投票（1，123），Server3產生投票（3，122）。然後各自將這個投票發送給集羣中所有機器
• 接收來自各個服務器的投票
• 處理投票
  • 投票的PK和上面規則一樣，顯然Server1會成爲Leader。
• 統計投票
• 改變服務器狀態

算法分析

首選介紹一些專業術語

術語解釋

SID：服務器ID。是一個數字，用來唯一標識Zookeeper集羣中的一臺機器。

ZXID：事務ID。用來唯一標識一次服務器狀態變更。在某一時刻，集羣中每臺機器的ZXID值不一定完全一致。

Vote：投票。通過投票選出Leader。爲（myId，ZXID）的形式

Quorum：指Zookeeper集羣中過半的機器數。如果集羣總機器數是n，那麼quorum=（2/n）+ 1;

下面開始算法分析：

進入Leader選舉

當Zookeeper集羣中一臺服務器出現下面2種情況之一時，就會進入Leader選舉：

• 服務器初始化啓動
• 服務器無法和Leader保持連接

當一臺機器進入Leader選舉流程時，當前集羣也可能處於以下2種狀態：

• 集羣中本來就已經存在一個Leader
  • 會被告知Leader信息，當前機器僅僅需要和Leader服務器建立起連接，進行同步狀態
• 集羣中確實不存在Leader

第一次投票

當集羣中不存在Leader的時候，所有機器都試圖去尋找一個Leader，這種尋找Leader的狀態稱爲“LOCKING”。

當一臺機器處於LOCKING狀態，它就會向其他機器發送消息，我們稱這個消息爲“投票”。

這個投票消息中包含了2個最基本的信息：所推舉的服務器的SID和ZXID，分別代表了被推舉服務器的唯一標識和事務ID。

變更投票

集羣中每臺機器發出投票之後，也會收到其他機器發來的投票。每臺機器會根據規則，處理其他機器的投票，並以此決定是否需要變更自己的投票。（變更規則在《概述》裏面講了。）

然後把投票再一次發出去。

確定Leader

經過第二次投票以後，集羣中所有機器收到其他機器的投票，然後開始統計投票。如果一臺機器收到過半的投票，那麼該機器就稱爲Leader。

小結

簡單來說，哪臺機器上的數據越新，越有可能成爲Leader。原因很簡單，數據越新，那麼該機器的ZXID越大，越能夠保證數據的恢復，不丟失。

實現細節

本節講述FastLeaderElection的實現。

服務器狀態

LOOKING：尋找Leader狀態。當服務器處於該狀態時，它會認爲當前集羣中沒有Leader，因此需要進入Leader選舉流程。

FOLLOWING：跟隨者狀態。表明當前服務器的狀態是跟隨者（Follower）

LEADING：領導者狀態。表明當前服務器是領導者。

Observing：觀察者狀態，表明當前服務器是觀察者

投票數據結構

QuorumCnxManager

在Leader選舉過程中，QuorumCnxManager負責各個機器之間的網絡通訊。

QuorumCnxManager內部維護了一個消息隊列。用於保存接收到的、待發送的消息。除了接收隊列以外，所有隊列都按SID分組形成隊列集合。舉個例子，假設集羣中除了當前機器以外，還有4臺機器，那麼就會爲這4臺機器分別創建一個發送隊列，互不干擾。

爲了能夠互相投票，Zookeeper集羣中所有機器都必須要兩兩建立起網絡連接。QuorumCnxManager啓動的時候，會去監聽Leader選舉的通訊端口。爲了避免2臺機器之間重複建立TCP連接，Zookeeper規定2臺機器之間，只有SID大的機器能夠主動發起連接，否則斷開連接。如果當前服務器發送自己的SID更大，那麼就會斷開當前連接，然後主動去和其他服務器連接。

###FastLeaderElection

FastLeaderElection是選舉算法的核心部分，首先我們約定幾個概念：

• 內部投票：服務器自身的投票
• 外部投票：其他服務器發來的投票
• 選舉輪次：Leader選舉的輪次，稱爲logicalclock
• PK：內部投票和外部投票進行對比，確定是否需要變更內部投票

選票管理

算法核心

• 自增選舉輪次
  • Zookeeper規定了所有投票必須在同一選舉輪次中，纔有效。
    • Zookeeper在開始新一輪投票時，會將logicallock進行自增。（這樣子做是爲了避免之前選票的干擾）
• 初始化選票
  • 每個服務器都將自己選舉爲Leader
• 發送初始化選票
• 接收外部選票
• 判斷選舉輪次
  • 外部投票的選舉輪次大於內部投票
    • 發現自己的投票輪次落後了，那麼立即更新自己的選舉輪次，清空所有已經收到的投票，然後使用初始化投票來PK以確定是否變更內部投票。最終再將內部投票發送出去
  • 外部投票輪次小於內部投票
    • 服務器直接忽略該外部投票。重新返回接收外部選票的步驟
  • 外部投票和內部投票一致，那麼進入PK步驟
• 選票PK
• 變更投票
• 選票歸檔
  • 將收到的外部投票放入到選票集合。按服務器SID來區分
• 統計投票
• 更新服務器狀態

參考

https://blog.csdn.net/weixin_41098980/article/details/80109789

《Paxos到Zookeeper 分佈式一致性原理與實踐》