Google的三篇論文影響了很多很多人欧漱，也影響了很多很多系統(tǒng)兜挨。這三篇論文一直是分布式領(lǐng)域傳閱的經(jīng)典膏孟。根據(jù)MapReduce，于是我們有了Hadoop拌汇；根據(jù)GFS柒桑，于是我們有了HDFS；根據(jù)BigTable噪舀，于是我們有了HBase魁淳。而在這三篇論文里都提及Google的一個(gè)Lock Service —— Chubby，哦与倡，于是我們有了Zookeeper界逛。

隨著大數(shù)據(jù)的火熱，Hxx們已經(jīng)變得耳熟能詳蒸走，現(xiàn)在作為一個(gè)開發(fā)人員如果都不知道這幾個(gè)名詞出門都好像不好意思跟人打招呼仇奶。但實(shí)際上對(duì)我們這些非大數(shù)據(jù)開發(fā)人員而言，Zookeeper是比Hxx們可能接觸到更多的一個(gè)基礎(chǔ)服務(wù)。但是该溯，無奈的是它一直默默的位于二線岛抄，從來沒有Hxx們那么耀眼。那么到底什么是Zookeeper呢狈茉？Zookeeper可以用來干什么夫椭？我們將如何使用Zookeeper？Zookeeper又是怎么實(shí)現(xiàn)的氯庆？

什么是Zookeeper

在Zookeeper的官網(wǎng)上有這么一句話：ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services蹭秋。

這大概描述了Zookeeper主要是一個(gè)分布式服務(wù)協(xié)調(diào)框架，實(shí)現(xiàn)同步服務(wù)堤撵，配置維護(hù)和命名服務(wù)等分布式應(yīng)用仁讨。是一個(gè)高性能的分布式數(shù)據(jù)一致性解決方案。

通俗地講实昨，ZooKeeper是動(dòng)物園管理員洞豁，它是拿來管大象 Hadoop、鯨魚 HBase荒给、Kafka等的管理員丈挟。

Zookeeper和CAP的關(guān)系

作為一個(gè)分布式系統(tǒng)，分區(qū)容錯(cuò)性是一個(gè)必須要考慮的關(guān)鍵點(diǎn)志电。一個(gè)分布式系統(tǒng)一旦喪失了分區(qū)容錯(cuò)性曙咽，也就表示放棄了擴(kuò)展性。因?yàn)樵诜植际较到y(tǒng)中挑辆，網(wǎng)絡(luò)故障是經(jīng)常出現(xiàn)的例朱，一旦出現(xiàn)在這種問題就會(huì)導(dǎo)致整個(gè)系統(tǒng)不可用是絕對(duì)不能容忍的。所以之拨，大部分分布式系統(tǒng)都會(huì)在保證分區(qū)容錯(cuò)性的前提下在一致性和可用性之間做權(quán)衡茉继。

CAP關(guān)系

ZooKeeper是個(gè)CP（一致性+分區(qū)容錯(cuò)性）的，即任何時(shí)刻對(duì)ZooKeeper的訪問請(qǐng)求能得到一致的數(shù)據(jù)結(jié)果蚀乔，同時(shí)系統(tǒng)對(duì)網(wǎng)絡(luò)分割具備容錯(cuò)性烁竭；但是它不能保證每次服務(wù)請(qǐng)求的可用性。也就是在極端環(huán)境下吉挣，ZooKeeper可能會(huì)丟棄一些請(qǐng)求派撕，消費(fèi)者程序需要重新請(qǐng)求才能獲得結(jié)果。

ZooKeeper是分布式協(xié)調(diào)服務(wù)睬魂，它的職責(zé)是保證數(shù)據(jù)在其管轄下的所有服務(wù)之間保持同步终吼、一致；所以就不難理解為什么ZooKeeper被設(shè)計(jì)成CP而不是AP特性的了氯哮。而且际跪， 作為ZooKeeper的核心實(shí)現(xiàn)算法Zab，就是解決了分布式系統(tǒng)下數(shù)據(jù)如何在多個(gè)服務(wù)之間保持同步問題的。

Zookeeper節(jié)點(diǎn)特性及節(jié)點(diǎn)屬性分析

Zookeeper提供基于類似于文件系統(tǒng)的目錄節(jié)點(diǎn)樹方式的數(shù)據(jù)存儲(chǔ)姆打，但是Zookeeper并不是用來專門存儲(chǔ)數(shù)據(jù)的良姆，它的作用主要是用來維護(hù)和監(jiān)控你存儲(chǔ)的數(shù)據(jù)的狀態(tài)變化。通過監(jiān)控這些數(shù)據(jù)狀態(tài)的變化幔戏，從而可以達(dá)到基于數(shù)據(jù)的集群管理玛追。

數(shù)據(jù)模型

與Linux文件系統(tǒng)不同的是，Linux文件系統(tǒng)有目錄和文件的區(qū)別闲延，而Zookeeper的數(shù)據(jù)節(jié)點(diǎn)稱為ZNode痊剖，ZNode是Zookeeper中數(shù)據(jù)的最小單元，每個(gè)ZNode都可以保存數(shù)據(jù)垒玲，同時(shí)還可以掛載子節(jié)點(diǎn)陆馁，因此構(gòu)成了一個(gè)層次化的命名空間，稱為樹侍匙。

znode樹形結(jié)構(gòu)圖

Zookeeper中ZNode的節(jié)點(diǎn)創(chuàng)建時(shí)候是可以指定類型的氮惯，主要有下面幾種類型。

PERSISTENT：持久化ZNode節(jié)點(diǎn)想暗，一旦創(chuàng)建這個(gè)ZNode點(diǎn)存儲(chǔ)的數(shù)據(jù)不會(huì)主動(dòng)消失，除非是客戶端主動(dòng)的delete帘不。

EPHEMERAL：臨時(shí)ZNode節(jié)點(diǎn)说莫，Client連接到Zookeeper Service的時(shí)候會(huì)建立一個(gè)Session，之后用這個(gè)Zookeeper連接實(shí)例創(chuàng)建該類型的znode寞焙，一旦Client關(guān)閉了Zookeeper的連接储狭，服務(wù)器就會(huì)清除Session，然后這個(gè)Session建立的ZNode節(jié)點(diǎn)都會(huì)從命名空間消失捣郊×杀罚總結(jié)就是，這個(gè)類型的znode的生命周期是和Client建立的連接一樣的呛牲。

PERSISTENT_SEQUENTIAL：順序自動(dòng)編號(hào)的ZNode節(jié)點(diǎn)刮萌，這種znoe節(jié)點(diǎn)會(huì)根據(jù)當(dāng)前已近存在的ZNode節(jié)點(diǎn)編號(hào)自動(dòng)加 1，而且不會(huì)隨Session斷開而消失娘扩。

EPEMERAL_SEQUENTIAL：臨時(shí)自動(dòng)編號(hào)節(jié)點(diǎn)着茸，ZNode節(jié)點(diǎn)編號(hào)會(huì)自動(dòng)增加，但是會(huì)隨Session消失而消失

Watcher數(shù)據(jù)變更通知

Zookeeper使用Watcher機(jī)制實(shí)現(xiàn)分布式數(shù)據(jù)的發(fā)布/訂閱功能琐旁。

Watcher機(jī)制

Zookeeper的Watcher機(jī)制主要包括客戶端線程涮阔、客戶端WatcherManager、Zookeeper服務(wù)器三部分灰殴【刺兀客戶端在向Zookeeper服務(wù)器注冊(cè)的同時(shí)，會(huì)將Watcher對(duì)象存儲(chǔ)在客戶端的WatcherManager當(dāng)中。當(dāng)Zookeeper服務(wù)器觸發(fā)Watcher事件后伟阔，會(huì)向客戶端發(fā)送通知辣之，客戶端線程從WatcherManager中取出對(duì)應(yīng)的Watcher對(duì)象來執(zhí)行回調(diào)邏輯。

ACL保障數(shù)據(jù)的安全

Zookeeper內(nèi)部存儲(chǔ)了分布式系統(tǒng)運(yùn)行時(shí)狀態(tài)的元數(shù)據(jù)减俏，這些元數(shù)據(jù)會(huì)直接影響基于Zookeeper進(jìn)行構(gòu)造的分布式系統(tǒng)的運(yùn)行狀態(tài)召烂，如何保障系統(tǒng)中數(shù)據(jù)的安全，從而避免因誤操作而帶來的數(shù)據(jù)隨意變更而導(dǎo)致的數(shù)據(jù)庫(kù)異常十分重要娃承，Zookeeper提供了一套完善的ACL權(quán)限控制機(jī)制來保障數(shù)據(jù)的安全奏夫。

我們可以從三個(gè)方面來理解ACL機(jī)制：權(quán)限模式 Scheme、授權(quán)對(duì)象 ID历筝、權(quán)限 Permission酗昼，通常使用"scheme:id:permission"來標(biāo)識(shí)一個(gè)有效的ACL信息。

內(nèi)存數(shù)據(jù)

Zookeeper的數(shù)據(jù)模型是樹結(jié)構(gòu)梳猪，在內(nèi)存數(shù)據(jù)庫(kù)中麻削，存儲(chǔ)了整棵樹的內(nèi)容，包括所有的節(jié)點(diǎn)路徑春弥、節(jié)點(diǎn)數(shù)據(jù)呛哟、ACL信息，Zookeeper會(huì)定時(shí)將這個(gè)數(shù)據(jù)存儲(chǔ)到磁盤上匿沛。

DataTree：DataTree是內(nèi)存數(shù)據(jù)存儲(chǔ)的核心扫责，是一個(gè)樹結(jié)構(gòu)，代表了內(nèi)存中一份完整的數(shù)據(jù)逃呼。DataTree不包含任何與網(wǎng)絡(luò)鳖孤、客戶端連接及請(qǐng)求處理相關(guān)的業(yè)務(wù)邏輯，是一個(gè)獨(dú)立的組件抡笼。

DataNode：DataNode是數(shù)據(jù)存儲(chǔ)的最小單元苏揣，其內(nèi)部除了保存了結(jié)點(diǎn)的數(shù)據(jù)內(nèi)容、ACL列表推姻、節(jié)點(diǎn)狀態(tài)之外平匈，還記錄了父節(jié)點(diǎn)的引用和子節(jié)點(diǎn)列表兩個(gè)屬性，其也提供了對(duì)子節(jié)點(diǎn)列表進(jìn)行操作的接口拾碌。

ZKDatabase：Zookeeper的內(nèi)存數(shù)據(jù)庫(kù)吐葱，管理Zookeeper的所有會(huì)話、DataTree存儲(chǔ)和事務(wù)日志校翔。ZKDatabase會(huì)定時(shí)向磁盤dump快照數(shù)據(jù)弟跑，同時(shí)在Zookeeper啟動(dòng)時(shí)，會(huì)通過磁盤的事務(wù)日志和快照文件恢復(fù)成一個(gè)完整的內(nèi)存數(shù)據(jù)庫(kù)防症。

Zookeeper的實(shí)現(xiàn)原理分析

1. Zookeeper Service網(wǎng)絡(luò)結(jié)構(gòu)

Zookeeper的工作集群可以簡(jiǎn)單分成兩類孟辑，一個(gè)是Leader哎甲，唯一一個(gè)，其余的都是follower饲嗽，如何確定Leader是通過內(nèi)部選舉確定的炭玫。

Zookeeper架構(gòu)圖

Leader和各個(gè)follower是互相通信的，對(duì)于Zookeeper系統(tǒng)的數(shù)據(jù)都是保存在內(nèi)存里面的貌虾，同樣也會(huì)備份一份在磁盤上吞加。

如果Leader掛了，Zookeeper集群會(huì)重新選舉尽狠，在毫秒級(jí)別就會(huì)重新選舉出一個(gè)Leader衔憨。

集群中除非有一半以上的Zookeeper節(jié)點(diǎn)掛了，Zookeeper Service才不可用袄膏。

2. Zookeeper讀寫數(shù)據(jù)

zk讀取數(shù)據(jù)流程

寫數(shù)據(jù)践图，一個(gè)客戶端進(jìn)行寫數(shù)據(jù)請(qǐng)求時(shí)，如果是follower接收到寫請(qǐng)求沉馆，就會(huì)把請(qǐng)求轉(zhuǎn)發(fā)給Leader码党，Leader通過內(nèi)部的Zab協(xié)議進(jìn)行原子廣播，直到所有Zookeeper節(jié)點(diǎn)都成功寫了數(shù)據(jù)后（內(nèi)存同步以及磁盤更新）斥黑，這次寫請(qǐng)求算是完成揖盘，然后Zookeeper Service就會(huì)給Client發(fā)回響應(yīng)。

讀數(shù)據(jù)锌奴，因?yàn)榧褐兴械腪ookeeper節(jié)點(diǎn)都呈現(xiàn)一個(gè)同樣的命名空間視圖（就是結(jié)構(gòu)數(shù)據(jù)）扣讼，上面的寫請(qǐng)求已經(jīng)保證了寫一次數(shù)據(jù)必須保證集群所有的Zookeeper節(jié)點(diǎn)都是同步命名空間的，所以讀的時(shí)候可以在任意一臺(tái)Zookeeper節(jié)點(diǎn)上缨叫。

3. Zookeeper工作原理

Zab協(xié)議

Zookeeper的核心是廣播，這個(gè)機(jī)制保證了各個(gè)Server之間的同步荔燎。實(shí)現(xiàn)這個(gè)機(jī)制的協(xié)議叫做Zab協(xié)議耻姥。

Zab（ZooKeeper Atomic Broadcast）原子消息廣播協(xié)議作為數(shù)據(jù)一致性的核心算法，Zab協(xié)議是專為Zookeeper設(shè)計(jì)的支持崩潰恢復(fù)原子消息廣播算法琐簇。

Zab協(xié)議核心如下：

所有的事務(wù)請(qǐng)求必須一個(gè)全局唯一的服務(wù)器（Leader）來協(xié)調(diào)處理，集群其余的服務(wù)器稱為follower服務(wù)器婉商。Leader服務(wù)器負(fù)責(zé)將一個(gè)客戶端請(qǐng)求轉(zhuǎn)化為事務(wù)提議（Proposal）渣叛，并將該proposal分發(fā)給集群所有的follower服務(wù)器。之后Leader服務(wù)器需要等待所有的follower服務(wù)器的反饋淳衙，一旦超過了半數(shù)的follower服務(wù)器進(jìn)行了正確反饋后饺著，那么Leader服務(wù)器就會(huì)再次向所有的follower服務(wù)器分發(fā)commit消息肠牲，要求其將前一個(gè)proposal進(jìn)行提交幼衰。

Zab模式

Zab協(xié)議包括兩種基本的模式：崩潰恢復(fù)和消息廣播。

當(dāng)整個(gè)服務(wù)框架啟動(dòng)過程中或Leader服務(wù)器出現(xiàn)網(wǎng)絡(luò)中斷缀雳、崩潰退出與重啟等異常情況時(shí)渡嚣，Zab協(xié)議就會(huì)進(jìn)入恢復(fù)模式并選舉產(chǎn)生新的Leader服務(wù)器。

當(dāng)選舉產(chǎn)生了新的Leader服務(wù)器肥印，同時(shí)集群中已經(jīng)有過半的機(jī)器與該Leader服務(wù)器完成了狀態(tài)同步之后识椰，Zab協(xié)議就會(huì)退出恢復(fù)模式，狀態(tài)同步是指數(shù)據(jù)同步竖独，用來保證集群在過半的機(jī)器能夠和Leader服務(wù)器的數(shù)據(jù)狀態(tài)保持一致裤唠。

當(dāng)集群中已經(jīng)有過半的Follower服務(wù)器完成了和Leader服務(wù)器的狀態(tài)同步，那么整個(gè)服務(wù)框架就可以進(jìn)入消息廣播模式莹痢。

當(dāng)一臺(tái)同樣遵守Zab協(xié)議的服務(wù)器啟動(dòng)后加入到集群中种蘸，如果此時(shí)集群中已經(jīng)存在一個(gè)Leader服務(wù)器在負(fù)責(zé)進(jìn)行消息廣播，那么加入的服務(wù)器就會(huì)自覺地進(jìn)入數(shù)據(jù)恢復(fù)模式：找到Leader所在的服務(wù)器竞膳，并與其進(jìn)行數(shù)據(jù)同步航瞭，然后一起參與到消息廣播流程中去。

Zookeeper只允許唯一的一個(gè)Leader服務(wù)器來進(jìn)行事務(wù)請(qǐng)求的處理坦辟，Leader服務(wù)器在接收到客戶端的事務(wù)請(qǐng)求后刊侯，會(huì)生成對(duì)應(yīng)的事務(wù)提議并發(fā)起一輪廣播協(xié)議，而如果集群中的其他機(jī)器收到客戶端的事務(wù)請(qǐng)求后锉走，那么這些非Leader服務(wù)器會(huì)首先將這個(gè)事務(wù)請(qǐng)求轉(zhuǎn)發(fā)給Leader服務(wù)器滨彻。

消息廣播

消息廣播

Zab協(xié)議的消息廣播過程使用是一個(gè)原子廣播協(xié)議，類似一個(gè)2PC提交過程挪蹭。具體的：

ZooKeeper使用單一主進(jìn)程Leader用于處理客戶端所有事務(wù)請(qǐng)求亭饵，并采用Zab的原子廣播協(xié)議，將服務(wù)器數(shù)據(jù)狀態(tài)變更以事務(wù)Proposal的形式廣播Follower上梁厉，因此能很好的處理客戶端的大量并發(fā)請(qǐng)求辜羊。

另一方面，由于事務(wù)間可能存在著依賴關(guān)系词顾，Zab協(xié)議保證Leader廣播的變更序列被順序的處理硬霍，有些狀態(tài)的變更必須依賴于比它早生成的那些狀態(tài)變更漠秋。

最后吱抚，考慮到主進(jìn)程Leader在任何時(shí)候可能崩潰或者異常退出国拇， 因此Zab協(xié)議還要Leader進(jìn)程崩潰的時(shí)候可以重新選出Leader并且保證數(shù)據(jù)的完整性舍悯；Follower收到Proposal后，寫到磁盤饮醇，返回Ack朴艰。Leader收到大多數(shù)ACK后祠墅，廣播Commit消息歌径，自己也提交該消息回铛。Follower收到Commit之后茵肃，提交該消息。

Zab協(xié)議簡(jiǎn)化了2PC事務(wù)提交：

去除中斷邏輯移除捞附，follower要么ack鸟召，要么拋棄Leader药版。

Leader不需要所有的Follower都響應(yīng)成功，只要一個(gè)多數(shù)派Ack即可肢础。

崩潰恢復(fù)

上面我們講了Zab協(xié)議在正常情況下的消息廣播過程传轰，那么一旦Leader服務(wù)器出現(xiàn)崩潰或者與過半的follower服務(wù)器失去聯(lián)系谷婆，就進(jìn)入崩潰恢復(fù)模式。

恢復(fù)模式需要重新選舉出一個(gè)新的Leader跟匆，讓所有的Server都恢復(fù)到一個(gè)正確的狀態(tài)通砍。

Zookeeper實(shí)踐封孙，共享鎖虎忌，Leader選舉

分布式鎖用于控制分布式系統(tǒng)之間同步訪問共享資源的一種方式膜蠢，可以保證不同系統(tǒng)訪問一個(gè)或一組資源時(shí)的一致性狡蝶，主要分為排它鎖和共享鎖贪惹。

排它鎖又稱為寫鎖或獨(dú)占鎖，若事務(wù)T1對(duì)數(shù)據(jù)對(duì)象O1加上了排它鎖枫绅，那么在整個(gè)加鎖期間并淋，只允許事務(wù)T1對(duì)O1進(jìn)行讀取和更新操作县耽，其他任何事務(wù)都不能再對(duì)這個(gè)數(shù)據(jù)對(duì)象進(jìn)行任何類型的操作兔毙，直到T1釋放了排它鎖澎剥。

獨(dú)占鎖

共享鎖又稱為讀鎖哑姚，若事務(wù)T1對(duì)數(shù)據(jù)對(duì)象O1加上共享鎖叙量，那么當(dāng)前事務(wù)只能對(duì)O1進(jìn)行讀取操作宛乃，其他事務(wù)也只能對(duì)這個(gè)數(shù)據(jù)對(duì)象加共享鎖，直到該數(shù)據(jù)對(duì)象上的所有共享鎖都被釋放析既。

共享鎖

Leader選舉

Leader選舉是保證分布式數(shù)據(jù)一致性的關(guān)鍵所在眼坏。當(dāng)Zookeeper集群中的一臺(tái)服務(wù)器出現(xiàn)以下兩種情況之一時(shí)宰译，需要進(jìn)入Leader選舉沿侈。

服務(wù)器初始化啟動(dòng)缀拭。

服務(wù)器運(yùn)行期間無法和Leader保持連接蛛淋。

Zookeeper在3.4.0版本后只保留了TCP版本的 FastLeaderElection 選舉算法褐荷。當(dāng)一臺(tái)機(jī)器進(jìn)入Leader選舉時(shí)叛甫，當(dāng)前集群可能會(huì)處于以下兩種狀態(tài)：

集群中已存在Leader。

集群中不存在Leader缀台。

對(duì)于集群中已經(jīng)存在Leader而言膛腐，此種情況一般都是某臺(tái)機(jī)器啟動(dòng)得較晚辩涝，在其啟動(dòng)之前怔揩，集群已經(jīng)在正常工作商膊，對(duì)這種情況宠进，該機(jī)器試圖去選舉Leader時(shí)实幕，會(huì)被告知當(dāng)前服務(wù)器的Leader信息堤器，對(duì)于該機(jī)器而言闸溃，僅僅需要和Leader機(jī)器建立起連接掂为，并進(jìn)行狀態(tài)同步即可勇哗。

而在集群中不存在Leader情況下則會(huì)相對(duì)復(fù)雜欲诺，其步驟如下：

(1) 第一次投票扰法。無論哪種導(dǎo)致進(jìn)行Leader選舉塞颁，集群的所有機(jī)器都處于試圖選舉出一個(gè)Leader的狀態(tài)酷窥，即LOOKING狀態(tài)蓬推，LOOKING機(jī)器會(huì)向所有其他機(jī)器發(fā)送消息，該消息稱為投票澡腾。投票中包含了SID（服務(wù)器的唯一標(biāo)識(shí)）和ZXID（事務(wù)ID）沸伏，(SID, ZXID)形式來標(biāo)識(shí)一次投票信息。假定Zookeeper由5臺(tái)機(jī)器組成动分，SID分別為1毅糟、2、3刺啦、4留特、5，ZXID分別為9玛瘸、9蜕青、9、8、8躏鱼，并且此時(shí)SID為2的機(jī)器是Leader機(jī)器茶行，某一時(shí)刻牧牢，1、2所在機(jī)器出現(xiàn)故障蹬蚁，因此集群開始進(jìn)行Leader選舉情连。在第一次投票時(shí)挽拔，每臺(tái)機(jī)器都會(huì)將自己作為投票對(duì)象倘是，于是SID為3匹表、4、5的機(jī)器投票情況分別為(3, 9)，(4, 8)攘轩， (5, 8)。

(2) 變更投票。每臺(tái)機(jī)器發(fā)出投票后，也會(huì)收到其他機(jī)器的投票脯宿，每臺(tái)機(jī)器會(huì)根據(jù)一定規(guī)則來處理收到的其他機(jī)器的投票窟感，并以此來決定是否需要變更自己的投票躏嚎，這個(gè)規(guī)則也是整個(gè)Leader選舉算法的核心所在戈鲁，其中術(shù)語(yǔ)描述如下

vote_sid：接收到的投票中所推舉Leader服務(wù)器的SID喂饥。

vote_zxid：接收到的投票中所推舉Leader服務(wù)器的ZXID。

self_sid：當(dāng)前服務(wù)器自己的SID。

self_zxid：當(dāng)前服務(wù)器自己的ZXID。

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

規(guī)則一：如果vote_zxid大于self_zxid，就認(rèn)可當(dāng)前收到的投票彼宠，并再次將該投票發(fā)送出去凭峡。

規(guī)則二：如果vote_zxid小于self_zxid，那么堅(jiān)持自己的投票康谆，不做任何變更。

規(guī)則三：如果vote_zxid等于self_zxid，那么就對(duì)比兩者的SID碗短，如果vote_sid大于self_sid，那么就認(rèn)可當(dāng)前收到的投票题涨，并再次將該投票發(fā)送出去偎谁。

規(guī)則四：如果vote_zxid等于self_zxid总滩，并且vote_sid小于self_sid，那么堅(jiān)持自己的投票巡雨，不做任何變更闰渔。

結(jié)合上面規(guī)則，給出下面的集群變更過程铐望。

Leader選舉

(3) 確定Leader冈涧。經(jīng)過第二輪投票后，集群中的每臺(tái)機(jī)器都會(huì)再次接收到其他機(jī)器的投票正蛙，然后開始統(tǒng)計(jì)投票督弓，如果一臺(tái)機(jī)器收到了超過半數(shù)的相同投票，那么這個(gè)投票對(duì)應(yīng)的SID機(jī)器即為L(zhǎng)eader乒验。此時(shí)Server3將成為L(zhǎng)eader愚隧。

作者：AskHarries