Leader選舉的概念和作用是什么

本篇內容主要講解“Leader選舉的概念和作用是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Leader選舉的概念和作用是什么”吧!

一、前言

1. 基本概念

• SID：服務器ID，用來標示ZooKeeper集群中的機器，每臺機器不能重復，和myid的值一致

• ZXID：事務ID

• Vote: 選票，具體的數據結構后面有

• Quorum：過半機器數

• logicalclock：邏輯時鐘（選舉輪次），zk服務器Leader選舉的輪次

服務器類型：

在zk中，引入了Leader、Follwer和Observer三種角色。zk集群中的所有機器通過一個Leader選舉過程來選定一臺被稱為Leader的機器，Leader服務器為客戶端提供讀和寫服務。Follower和Observer都能夠提供讀服務，唯一的區別在于，Observer機器不參與Leader選舉過程，也不參與寫操作的過半寫成功策略。因此，Observer存在的意義是：在不影響寫性能的情況下提升集群的讀性能。

服務器狀態：

• LOOKING：Leader選舉階段；

• FOLLOWING：Follower服務器和Leader保持同步狀態；

• LEADING：Leader服務器作為主進程領導狀態；

• OBSERVING：觀察者狀態，表明當前服務器是Observer，不參與投票；

選舉的目的就是選擇出合適的Leader機器，由Leader機器決定事務性的Proposal處理過程，實現類兩階段提交協議（具體是ZAB協議）。

二、啟動選舉主流程

在zk服務器集群啟動過程中，經QuorumPeerMain中，不光會創建ZooKeeperServer對象，同時會生成QuorumPeer對象，代表了ZooKeeper集群中的一臺機器。在整個機器運行期間，負責維護該機器的運行狀態，同時會根據情況發起Leader選舉。

QuorumPeer是一個獨立的線程，維護著zk機器的狀態。

本次主要介紹的是選舉相關的內容，之后的行文都是從startLeaderElection中衍生出來的。

1. QuorumPeer維護集群機器狀態

QuorumPeer的職責就是不斷地檢測當前的zk機器的狀態，執行對應的邏輯，簡單來說，就是根據服務所處的不同狀態執行不同的邏輯。為了避免篇幅過長，影響閱讀體驗，刪除了一部分邏輯后，代碼如下：

當機器處于LOOKING狀態時，QuorumPeer會進行選舉，但是具體的邏輯并不是由QuorumPeer來負責的，整體的投票過程獨立出來了，從邏輯執行的角度看，整個過程設計到兩個主要的環節：

• 與其他的zk集群機器通信的過程

• 實現具體的選舉算法

QuorumPeer中默認使用的選舉算法是FastLeaderElection。

三、 選舉過程中的整體架構

zk提拱多種選舉算法 不過之前版本的都廢棄掉了，一般默認使用FastLeaderElection 也就是在配置文件中設置 electorArg=3。在集群啟動的過程中，QuorumPeer會根據配置實現不同的選舉策略：

QuorumCnxManager、 Listener、 SendWorker、 RecvWorker 的分工很明確 準確的說 QuorumCnxManager這個類的職責也很明確，就是負責監聽端口 發消息 讀消息 其中：

• Listener 監聽連接，維護與其他服務器的連接；

• SendWorker 負責根據Listener保存的連接信息 向對應的server發送（投票）信息；

• RecvWorker 獲取其他server的（投票）信息 并存入隊列；

對于每一臺zk機器，都需要建立一個TCP的端口監聽，在QuorumCnxManager中交給Listener來處理，使用的是Socket的阻塞式IO（默認監聽的端口是3888，是在config文件里面設置的）。在兩兩相互連接的過程中，為了避免兩臺機器之間重復地創建TCP連接，zk制定了連接的規則：只允許SID打的服務器主動和其他服務器建立連接。實現的方式也比較簡單，在receiveConnection中，服務器會對比與自己建立連接的服務器的SID，判斷是否接受請求，如果自己的SID更大，那么會斷開連接，然后自己主動去和遠程服務器建立連接。這段邏輯是由Listener來做的，且Listener獨立線程。核心代碼如下：

QuorumCnxManager這里只負責與其他server的信息交換 但不負責信息的生成與處理 數據的處理就要交給對應的選舉算法進行處理了。

以上內容主要是建立各臺zk服務器之間的連接通信過程，具體的選舉策略zk抽象成了Election，主要分析的是FastLeaderElection方式（選舉算法的核心部分）：

2. 將自己作為新的Leader投出去（我選我）

3. 驗證當前自己的選票與大家的選票誰更適合做Leader

這里有一些點還是比較難以理解的，比如當從票箱取出的選票為null時需要判斷當前服務器是集群其他服務器是否保持連接狀態，不過都已經標注了詳細的注釋，相信仔細看兩遍一定可以理解的。

這里的 recvqueue 就是所有收到其它服務器投票后的票箱（帶頭結點的單向鏈表），recvqueue.poll 即取出第一票，這里我們看下poll方法做的操作：

到了這一步，開始遍歷當前服務器收到的選票中是否已經有過半的參與者選擇了當前服務器的選票（經過上面的步驟，當前服務器選票已經修改為最合適的），我們一起看下 org.apache.zookeeper.server.quorum.FastLeaderElection#termPredicate 方法:

如果當前選票沒有過半，直接break繼續取下一票進行判斷，這個很好理解。

可是問題來了，如果已經過半了，后面的這個步驟為什么還要取下一票在和當前選票比看誰更適合呢？

我們一起來看下面的代碼：

我初次看的時候也是難以理解，為什么取出下一票后判斷比當前選票更合適后要在將選票放回去，然后break呢？

上面的代碼我已經寫了注釋，這個while 循環的目的是要遍歷完票箱防止有比當前更合適的選票， 如果 n==null 則說明沒有找到任何比當前“過半選票更合適的選票”，進行收尾工作，修改當前主機狀態：

 proposedLeader == self.getId()) ?
         ServerState.LEADING: learningState()

然后清空隊列，返回最終選票。

如果剩下的選票中有比自己更合適的則將其放回票箱，重新走一遍前面的流程，修改當前選票廣播。

說明：票箱也就是當前接收選票的容器 recvset，本質是一個HashMap，key為投票者的serverId，所以收到多次投票也只是更新選票而已，設計很是巧妙呀！

5. 無需選舉的情況

最后這塊的代碼雖然不多，可是卻是最難理解的，上面的注釋中分析了為什么選舉過程中可以收到通知發送者狀態為FOLLOWING, LEADING, OBSERVING 的情況，結合注釋還得仔細的看幾遍，其實就是為了處理下面這三種情況下的選舉狀態：

1. 新的Server(非Observer)加入到正常運行的集群

2. 當Leader掛了，并不是所有follower都同時能夠感知到leader掛了，先感知到的server會發送通知給其它server，但由于其它server還未感知到，所以它們發送給這個server的通知狀態就是FOLLOWING

3. 本輪選舉中其它Server已經選舉出了新的leader，但還沒有通知到當前server，這些已經知道leader選舉完畢的server向該server發送的通知就是LEADING或FOLLOWING

五、總結

以上就是zk的默認選舉流程，按照ZAB協議的兩種狀態分析：

• 初始化的時候，處于同一輪次進行投票直到投票選擇出一個Leader

• 崩潰恢復階段：

1. Leader服務器掛了，那么經歷的和初始化流程類似的過程，選擇Leader

2. Follower服務器掛了，那么自己在執行選舉的過程中，會收到其他服務器給的Leader選票信息（對應上文無需選舉情況中的分支代碼），也可以確定Leader所屬

到此，相信大家對“Leader選舉的概念和作用是什么”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！