《從Paxos到ZooKeeper 分佈式一致性原理與實踐》閱讀【Leader選舉】

從3.4.0版本開始，zookeeper廢棄了0、一、2這3種Leader選舉算法，只保留了TCP版本的FastLeaderElection選舉算法。

當ZooKeeper集羣中的一臺服務器出現如下兩種狀況之一時，就會開始進入Leader選舉。

　　一、服務器初始化啓動。

　　二、服務器運行期間沒法和Leader保持鏈接。

而當一臺機器進入Leader選舉流程時，當前集羣也可能會處於如下兩種狀態。

　　一、集羣中原本就已經存在一個Leader。

　　二、集羣中確實不存在Leader。

Leader選舉算法分析

　　對於集羣中已經存在Leader而言，此種狀況通常都是某臺機器啓動得較晚，在其啓動以前，集羣已經在正常工做，對這種狀況，該機器試圖去選舉Leader時，會被告知當前服務器的Leader信息，對於該機器而言，僅僅須要和Leader機器創建起鏈接，並進行狀態同步便可。而在集羣中不存在Leader狀況下則會相對複雜，其步驟以下

　　(1) 第一次投票。不管哪一種致使進行Leader選舉，集羣的全部機器都處於試圖選舉出一個Leader的狀態，即LOOKING狀態，LOOKING機器會向全部其餘機器發送消息，該消息稱爲投票。投票中包含了SID（服務器的惟一標識）和ZXID（事務ID），(SID, ZXID)形式來標識一次投票信息。假定Zookeeper由5臺機器組成，SID分別爲一、二、三、四、5，ZXID分別爲九、九、九、八、8，而且此時SID爲2的機器是Leader機器，某一時刻，一、2所在機器出現故障，所以集羣開始進行Leader選舉。在第一次投票時，每臺機器都會將本身做爲投票對象，因而SID爲三、四、5的機器投票狀況分別爲(3, 9)，(4, 8)， (5, 8)。

　　(2) 變動投票。每臺機器發出投票後，也會收到其餘機器的投票，每臺機器會根據必定規則來處理收到的其餘機器的投票，並以此來決定是否須要變動本身的投票，這個規則也是整個Leader選舉算法的核心所在，其中術語描述以下

　　　　· vote_sid：接收到的投票中所推舉Leader服務器的SID。

　　　　· vote_zxid：接收到的投票中所推舉Leader服務器的ZXID。

　　　　· self_sid：當前服務器本身的SID。

　　　　· self_zxid：當前服務器本身的ZXID。

　　每次對收到的投票的處理，都是對(vote_sid, vote_zxid)和(self_sid, self_zxid)對比的過程。

　　　　規則一：若是vote_zxid大於self_zxid，就承認當前收到的投票，並再次將該投票發送出去。

　　　　規則二：若是vote_zxid小於self_zxid，那麼堅持本身的投票，不作任何變動。

　　　　規則三：若是vote_zxid等於self_zxid，那麼就對比二者的SID，若是vote_sid大於self_sid，那麼就承認當前收到的投票，並再次將該投票發送出去。

　　　　規則四：若是vote_zxid等於self_zxid，而且vote_sid小於self_sid，那麼堅持本身的投票，不作任何變動。

　　結合上面規則，給出下面的集羣變動過程。

　　(3) 肯定Leader。通過第二輪投票後，集羣中的每臺機器都會再次接收到其餘機器的投票，而後開始統計投票，若是一臺機器收到了超過半數的相同投票，那麼這個投票對應的SID機器即爲Leader。此時Server3將成爲Leader。

　　由上面規則可知，一般那臺服務器上的數據越新（ZXID會越大），其成爲Leader的可能性越大，也就越可以保證數據的恢復。若是ZXID相同，則SID越大機會越大。

Leader選舉實現細節

　1. 服務器狀態

　　服務器具備四種狀態，分別是LOOKING、FOLLOWING、LEADING、OBSERVING。

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

　　FOLLOWING：跟隨者狀態。代表當前服務器角色是Follower。

　　LEADING：領導者狀態。代表當前服務器角色是Leader。

　　OBSERVING：觀察者狀態。代表當前服務器角色是Observer。

　2. 投票數據結構

　　每一個投票中包含了兩個最基本的信息，所推舉服務器的SID和ZXID，投票（Vote）在Zookeeper中包含字段以下

　　id：被推舉的Leader的SID。

　　zxid：被推舉的Leader事務ID。

　　electionEpoch：邏輯時鐘，用來判斷多個投票是否在同一輪選舉週期中，該值在服務端是一個自增序列，每次進入新一輪的投票後，都會對該值進行加1操做。

　　peerEpoch：被推舉的Leader的epoch。

　　state：當前服務器的狀態。

　3. QuorumCnxManager：網絡I/O

　　每臺服務器在啓動的過程當中，會啓動一個QuorumPeerManager，負責各臺服務器之間的底層Leader選舉過程當中的網絡通訊。

　　(1) 消息隊列。QuorumCnxManager內部維護了一系列的隊列，用來保存接收到的、待發送的消息以及消息的發送器，除接收隊列之外，其餘隊列都按照SID分組造成隊列集合，如一個集羣中除了自身還有3臺機器，那麼就會爲這3臺機器分別建立一個發送隊列，互不干擾。

　　　　· recvQueue：消息接收隊列，用於存放那些從其餘服務器接收到的消息。

　　　　· queueSendMap：消息發送隊列，用於保存那些待發送的消息，按照SID進行分組。

　　　　· senderWorkerMap：發送器集合，每一個SenderWorker消息發送器，都對應一臺遠程Zookeeper服務器，負責消息的發送，也按照SID進行分組。

　　　　· lastMessageSent：最近發送過的消息，爲每一個SID保留最近發送過的一個消息。

　　(2) 創建鏈接。爲了可以相互投票，Zookeeper集羣中的全部機器都須要兩兩創建起網絡鏈接。QuorumCnxManager在啓動時會建立一個ServerSocket來監聽Leader選舉的通訊端口(默認爲3888)。開啓監聽後，Zookeeper可以不斷地接收到來自其餘服務器的建立鏈接請求，在接收到其餘服務器的TCP鏈接請求時，會進行處理。爲了不兩臺機器之間重複地建立TCP鏈接，Zookeeper只容許SID大的服務器主動和其餘機器創建鏈接，不然斷開鏈接。在接收到建立鏈接請求後，服務器經過對比本身和遠程服務器的SID值來判斷是否接收鏈接請求，若是當前服務器發現本身的SID更大，那麼會斷開當前鏈接，而後本身主動和遠程服務器創建鏈接。一旦鏈接創建，就會根據遠程服務器的SID來建立相應的消息發送器SendWorker和消息接收器RecvWorker，並啓動。

　　(3) 消息接收與發送。消息接收：由消息接收器RecvWorker負責，因爲Zookeeper爲每一個遠程服務器都分配一個單獨的RecvWorker，所以，每一個RecvWorker只須要不斷地從這個TCP鏈接中讀取消息，並將其保存到recvQueue隊列中。消息發送：因爲Zookeeper爲每一個遠程服務器都分配一個單獨的SendWorker，所以，每一個SendWorker只須要不斷地從對應的消息發送隊列中獲取出一個消息發送便可，同時將這個消息放入lastMessageSent中。在SendWorker中，一旦Zookeeper發現針對當前服務器的消息發送隊列爲空，那麼此時須要從lastMessageSent中取出一個最近發送過的消息來進行再次發送，這是爲了解決接收方在消息接收前或者接收到消息後服務器掛了，致使消息還沒有被正確處理。同時，Zookeeper可以保證接收方在處理消息時，會對重複消息進行正確的處理。

　4. FastLeaderElection：選舉算法核心

　　· 外部投票：特指其餘服務器發來的投票。

　　· 內部投票：服務器自身當前的投票。

　　· 選舉輪次：Zookeeper服務器Leader選舉的輪次，即logicalclock。

　　· PK：對內部投票和外部投票進行對比來肯定是否須要變動內部投票。

　　(1) 選票管理

　　· sendqueue：選票發送隊列，用於保存待發送的選票。

　　· recvqueue：選票接收隊列，用於保存接收到的外部投票。

　　· WorkerReceiver：選票接收器。其會不斷地從QuorumCnxManager中獲取其餘服務器發來的選舉消息，並將其轉換成一個選票，而後保存到recvqueue中，在選票接收過程當中，若是發現該外部選票的選舉輪次小於當前服務器的，那麼忽略該外部投票，同時當即發送本身的內部投票。

　　· WorkerSender：選票發送器，不斷地從sendqueue中獲取待發送的選票，並將其傳遞到底層QuorumCnxManager中。

　　(2) 算法核心

　　上圖展現了FastLeaderElection模塊是如何與底層網絡I/O進行交互的。Leader選舉的基本流程以下

　　1. 自增選舉輪次。Zookeeper規定全部有效的投票都必須在同一輪次中，在開始新一輪投票時，會首先對logicalclock進行自增操做。

　　2. 初始化選票。在開始進行新一輪投票以前，每一個服務器都會初始化自身的選票，而且在初始化階段，每臺服務器都會將本身推舉爲Leader。

　　3. 發送初始化選票。完成選票的初始化後，服務器就會發起第一次投票。Zookeeper會將剛剛初始化好的選票放入sendqueue中，由發送器WorkerSender負責發送出去。

　　4. 接收外部投票。每臺服務器會不斷地從recvqueue隊列中獲取外部選票。若是服務器發現沒法獲取到任何外部投票，那麼就會當即確認本身是否和集羣中其餘服務器保持着有效的鏈接，若是沒有鏈接，則立刻創建鏈接，若是已經創建了鏈接，則再次發送本身當前的內部投票。

　　5. 判斷選舉輪次。在發送完初始化選票以後，接着開始處理外部投票。在處理外部投票時，會根據選舉輪次來進行不一樣的處理。

　　　　· 外部投票的選舉輪次大於內部投票。若服務器自身的選舉輪次落後於該外部投票對應服務器的選舉輪次，那麼就會當即更新本身的選舉輪次(logicalclock)，而且清空全部已經收到的投票，而後使用初始化的投票來進行PK以肯定是否變動內部投票。最終再將內部投票發送出去。

　　　　· 外部投票的選舉輪次小於內部投票。若服務器接收的外選票的選舉輪次落後於自身的選舉輪次，那麼Zookeeper就會直接忽略該外部投票，不作任何處理，並返回步驟4。

　　　　· 外部投票的選舉輪次等於內部投票。此時能夠開始進行選票PK。

　　6. 選票PK。在進行選票PK時，符合任意一個條件就須要變動投票。

　　　　· 若外部投票中推舉的Leader服務器的選舉輪次大於內部投票，那麼須要變動投票。

　　　　· 若選舉輪次一致，那麼就對比二者的ZXID，若外部投票的ZXID大，那麼須要變動投票。

　　　　· 若二者的ZXID一致，那麼就對比二者的SID，若外部投票的SID大，那麼就須要變動投票。

　　7. 變動投票。通過PK後，若肯定了外部投票優於內部投票，那麼就變動投票，即便用外部投票的選票信息來覆蓋內部投票，變動完成後，再次將這個變動後的內部投票發送出去。

　　8. 選票歸檔。不管是否變動了投票，都會將剛剛收到的那份外部投票放入選票集合recvset中進行歸檔。recvset用於記錄當前服務器在本輪次的Leader選舉中收到的全部外部投票（按照服務隊的SID區別，如{(1, vote1), (2, vote2)...}）。

　　9. 統計投票。完成選票歸檔後，就能夠開始統計投票，統計投票是爲了統計集羣中是否已經有過半的服務器承認了當前的內部投票，若是肯定已經有過半服務器承認了該投票，則終止投票。不然返回步驟4。

　　10. 更新服務器狀態。若已經肯定能夠終止投票，那麼就開始更新服務器狀態，服務器首選判斷當前被過半服務器承認的投票所對應的Leader服務器是不是本身，如果本身，則將本身的服務器狀態更新爲LEADING，若不是，則根據具體狀況來肯定本身是FOLLOWING或是OBSERVING。