本篇內(nèi)容主要講解“Leader選舉的概念和作用是什么”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“Leader選舉的概念和作用是什么”吧!

為貢井等地區(qū)用戶(hù)提供了全套網(wǎng)頁(yè)設(shè)計(jì)制作服務(wù)，及貢井網(wǎng)站建設(shè)行業(yè)解決方案。主營(yíng)業(yè)務(wù)為網(wǎng)站制作、成都做網(wǎng)站、貢井網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專(zhuān)業(yè)、用心的態(tài)度為用戶(hù)提供真誠(chéng)的服務(wù)。我們深信只要達(dá)到每一位用戶(hù)的要求，就會(huì)得到認(rèn)可，從而選擇與我們長(zhǎng)期合作。這樣，我們也可以走得更遠(yuǎn)！

一、前言

1. 基本概念

• SID：服務(wù)器ID，用來(lái)標(biāo)示ZooKeeper集群中的機(jī)器，每臺(tái)機(jī)器不能重復(fù)，和myid的值一致

• ZXID：事務(wù)ID

• Vote: 選票，具體的數(shù)據(jù)結(jié)構(gòu)后面有

• Quorum：過(guò)半機(jī)器數(shù)

• logicalclock：邏輯時(shí)鐘（選舉輪次），zk服務(wù)器Leader選舉的輪次

服務(wù)器類(lèi)型：

在zk中，引入了Leader、Follwer和Observer三種角色。zk集群中的所有機(jī)器通過(guò)一個(gè)Leader選舉過(guò)程來(lái)選定一臺(tái)被稱(chēng)為L(zhǎng)eader的機(jī)器，Leader服務(wù)器為客戶(hù)端提供讀和寫(xiě)服務(wù)。Follower和Observer都能夠提供讀服務(wù)，唯一的區(qū)別在于，Observer機(jī)器不參與Leader選舉過(guò)程，也不參與寫(xiě)操作的過(guò)半寫(xiě)成功策略。因此，Observer存在的意義是：在不影響寫(xiě)性能的情況下提升集群的讀性能。

服務(wù)器狀態(tài)：

• LOOKING：Leader選舉階段；

• FOLLOWING：Follower服務(wù)器和Leader保持同步狀態(tài)；

• LEADING：Leader服務(wù)器作為主進(jìn)程領(lǐng)導(dǎo)狀態(tài)；

• OBSERVING：觀察者狀態(tài)，表明當(dāng)前服務(wù)器是Observer，不參與投票；

選舉的目的就是選擇出合適的Leader機(jī)器，由Leader機(jī)器決定事務(wù)性的Proposal處理過(guò)程，實(shí)現(xiàn)類(lèi)兩階段提交協(xié)議（具體是ZAB協(xié)議）。

二、啟動(dòng)選舉主流程

在zk服務(wù)器集群?jiǎn)?dòng)過(guò)程中，經(jīng)QuorumPeerMain中，不光會(huì)創(chuàng)建ZooKeeperServer對(duì)象，同時(shí)會(huì)生成QuorumPeer對(duì)象，代表了ZooKeeper集群中的一臺(tái)機(jī)器。在整個(gè)機(jī)器運(yùn)行期間，負(fù)責(zé)維護(hù)該機(jī)器的運(yùn)行狀態(tài)，同時(shí)會(huì)根據(jù)情況發(fā)起Leader選舉。

QuorumPeer是一個(gè)獨(dú)立的線(xiàn)程，維護(hù)著zk機(jī)器的狀態(tài)。

本次主要介紹的是選舉相關(guān)的內(nèi)容，之后的行文都是從startLeaderElection中衍生出來(lái)的。

1. QuorumPeer維護(hù)集群機(jī)器狀態(tài)

QuorumPeer的職責(zé)就是不斷地檢測(cè)當(dāng)前的zk機(jī)器的狀態(tài)，執(zhí)行對(duì)應(yīng)的邏輯，簡(jiǎn)單來(lái)說(shuō)，就是根據(jù)服務(wù)所處的不同狀態(tài)執(zhí)行不同的邏輯。為了避免篇幅過(guò)長(zhǎng)，影響閱讀體驗(yàn)，刪除了一部分邏輯后，代碼如下：

當(dāng)機(jī)器處于LOOKING狀態(tài)時(shí)，QuorumPeer會(huì)進(jìn)行選舉，但是具體的邏輯并不是由QuorumPeer來(lái)負(fù)責(zé)的，整體的投票過(guò)程獨(dú)立出來(lái)了，從邏輯執(zhí)行的角度看，整個(gè)過(guò)程設(shè)計(jì)到兩個(gè)主要的環(huán)節(jié)：

• 與其他的zk集群機(jī)器通信的過(guò)程

• 實(shí)現(xiàn)具體的選舉算法

QuorumPeer中默認(rèn)使用的選舉算法是FastLeaderElection。

三、 選舉過(guò)程中的整體架構(gòu)

zk提拱多種選舉算法 不過(guò)之前版本的都廢棄掉了，一般默認(rèn)使用FastLeaderElection 也就是在配置文件中設(shè)置 electorArg=3。在集群?jiǎn)?dòng)的過(guò)程中，QuorumPeer會(huì)根據(jù)配置實(shí)現(xiàn)不同的選舉策略：

QuorumCnxManager、 Listener、 SendWorker、 RecvWorker的分工很明確 準(zhǔn)確的說(shuō) QuorumCnxManager這個(gè)類(lèi)的職責(zé)也很明確，就是負(fù)責(zé)監(jiān)聽(tīng)端口 發(fā)消息 讀消息 其中：

• Listener 監(jiān)聽(tīng)連接，維護(hù)與其他服務(wù)器的連接；

• SendWorker 負(fù)責(zé)根據(jù)Listener保存的連接信息 向?qū)?yīng)的server發(fā)送（投票）信息；

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

對(duì)于每一臺(tái)zk機(jī)器，都需要建立一個(gè)TCP的端口監(jiān)聽(tīng)，在QuorumCnxManager中交給Listener來(lái)處理，使用的是Socket的阻塞式IO（默認(rèn)監(jiān)聽(tīng)的端口是3888，是在config文件里面設(shè)置的）。在兩兩相互連接的過(guò)程中，為了避免兩臺(tái)機(jī)器之間重復(fù)地創(chuàng)建TCP連接，zk制定了連接的規(guī)則：只允許SID打的服務(wù)器主動(dòng)和其他服務(wù)器建立連接。實(shí)現(xiàn)的方式也比較簡(jiǎn)單，在receiveConnection中，服務(wù)器會(huì)對(duì)比與自己建立連接的服務(wù)器的SID，判斷是否接受請(qǐng)求，如果自己的SID更大，那么會(huì)斷開(kāi)連接，然后自己主動(dòng)去和遠(yuǎn)程服務(wù)器建立連接。這段邏輯是由Listener來(lái)做的，且Listener獨(dú)立線(xiàn)程。核心代碼如下：

QuorumCnxManager這里只負(fù)責(zé)與其他server的信息交換 但不負(fù)責(zé)信息的生成與處理 數(shù)據(jù)的處理就要交給對(duì)應(yīng)的選舉算法進(jìn)行處理了。

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

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

3. 驗(yàn)證當(dāng)前自己的選票與大家的選票誰(shuí)更適合做Leader

這里有一些點(diǎn)還是比較難以理解的，比如當(dāng)從票箱取出的選票為null時(shí)需要判斷當(dāng)前服務(wù)器是集群其他服務(wù)器是否保持連接狀態(tài)，不過(guò)都已經(jīng)標(biāo)注了詳細(xì)的注釋?zhuān)嘈抛屑?xì)看兩遍一定可以理解的。

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

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

如果當(dāng)前選票沒(méi)有過(guò)半，直接break繼續(xù)取下一票進(jìn)行判斷，這個(gè)很好理解。

可是問(wèn)題來(lái)了，如果已經(jīng)過(guò)半了，后面的這個(gè)步驟為什么還要取下一票在和當(dāng)前選票比看誰(shuí)更適合呢？

我們一起來(lái)看下面的代碼：

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

上面的代碼我已經(jīng)寫(xiě)了注釋?zhuān)@個(gè)while 循環(huán)的目的是要遍歷完票箱防止有比當(dāng)前更合適的選票， 如果 n==null 則說(shuō)明沒(méi)有找到任何比當(dāng)前“過(guò)半選票更合適的選票”，進(jìn)行收尾工作，修改當(dāng)前主機(jī)狀態(tài)：

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

然后清空隊(duì)列，返回最終選票。

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

說(shuō)明：票箱也就是當(dāng)前接收選票的容器 recvset，本質(zhì)是一個(gè)HashMap，key為投票者的serverId，所以收到多次投票也只是更新選票而已，設(shè)計(jì)很是巧妙呀！

5. 無(wú)需選舉的情況

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

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

2. 當(dāng)Leader掛了，并不是所有follower都同時(shí)能夠感知到leader掛了，先感知到的server會(huì)發(fā)送通知給其它server，但由于其它server還未感知到，所以它們發(fā)送給這個(gè)server的通知狀態(tài)就是FOLLOWING

3. 本輪選舉中其它Server已經(jīng)選舉出了新的leader，但還沒(méi)有通知到當(dāng)前server，這些已經(jīng)知道leader選舉完畢的server向該server發(fā)送的通知就是LEADING或FOLLOWING

五、總結(jié)

以上就是zk的默認(rèn)選舉流程，按照Z(yǔ)AB協(xié)議的兩種狀態(tài)分析：

• 初始化的時(shí)候，處于同一輪次進(jìn)行投票直到投票選擇出一個(gè)Leader

• 崩潰恢復(fù)階段：

1. Leader服務(wù)器掛了，那么經(jīng)歷的和初始化流程類(lèi)似的過(guò)程，選擇Leader

2. Follower服務(wù)器掛了，那么自己在執(zhí)行選舉的過(guò)程中，會(huì)收到其他服務(wù)器給的Leader選票信息（對(duì)應(yīng)上文無(wú)需選舉情況中的分支代碼），也可以確定Leader所屬

到此，相信大家對(duì)“Leader選舉的概念和作用是什么”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢(xún)，關(guān)注我們，繼續(xù)學(xué)習(xí)！