2021Java面試題合集-Zookeeper面試題

ZooKe叩er是什么？

?ZooKeeper是一個開源的分布式協(xié)調服務。它是一個為分布式應用提供一致性服務的軟件，分布

式應用程序可以基于Zookeeper實現諸如數據發(fā)布/訂閱、負載均衡、命名服務、分布式協(xié)調/通

知、集群管理、Master選舉、分布式鎖和分布式隊列等功能。

?ZooKeeper的目標就是封裝好復雜易出錯的關鍵服務，將簡單易用的接口和性能高效、功能穩(wěn)定

的系統(tǒng)提供給用戶。

?Zookeeper保證了如下分布式一致性特性：

(1)順序一致性

(2)原子性

(3)單一視圖

(4)可靠性

(5)實時性(最終一致性)

?客戶端的讀請求可以被集群中的任意一臺機器處理，如果讀請求在節(jié)點上注冊了監(jiān)聽器，這個監(jiān)聽

器也是由所連接的zookeeper機器來處理.對于寫請求，這些請求會同時發(fā)給其他zookeeper機

器并且達成一致后，請求才會返回成功。因此，隨著zookeeper的集群機器增多，讀請求的吞吐

會提高但是寫請求的吞吐會下降。

?有序性是zookeeper中非常重要的一個特性，所有的更新都是全局有序的，每個更新都有一個唯

一的時間戳，這個時間戳稱為zxid(ZookeeperTransactionId)。而讀請求只會相對于更新有

序，也就是讀請求的返回結果中會帶有這個zookeeper最新的zxid。

ZooKe叩er提供了什么？

?文件系統(tǒng)

?通知機制

Zookeeper文件系統(tǒng)

?Zookeeper提供一個多層級的節(jié)點命名空間(節(jié)點稱為znode)。與文件系統(tǒng)不同的是，這些節(jié)

點都可以設置關聯的數據，而文件系統(tǒng)中只有文件節(jié)點可以存放數據而目錄節(jié)點不行。

?Zookeeper為了保證高吞吐和低延遲，在內存中維護了這個樹狀的目錄結構，這種特性使得

Zookeeper不能用于存放大量的數據，每個節(jié)點的存放數據上限為1Mo

Zookeeper怎么保證主從節(jié)點的狀態(tài)同步？

?Zookeeper的核心是原子廣播機制，這個機制保證了各個server之間的同步。實現這個機制的協(xié)

議叫做Zab協(xié)議。Zab協(xié)議有兩種模式，它們分別是恢復模式和廣播模式。

恢復模式

?當服務啟動或者在領導者崩潰后，Zab就進入了恢復模式，當領導者被選舉出來，且大多數server

完成了和leader的狀態(tài)同步以后，恢復模式就結束了。狀態(tài)同步保證了leader和server具有相

同的系統(tǒng)狀態(tài)。

廣播模式

?一旦leader已經和多數的follower進行了狀態(tài)同步后，它就可以開始廣播消息了，即進入廣播狀

態(tài)。這時候當一個server加入ZooKeeper服務中，它會在恢復模式下啟動，發(fā)現leader,并和

leader進行狀態(tài)同步。待到同步結束，它也參與消息廣播。ZooKeeper服務一直維持在

Broadcast狀態(tài)，直到leader崩潰了或者leader失去了大部分的followers支持。

四種類型的數據節(jié)點Znode

?(1)PERSISTENT-持久節(jié)點除非手動刪除，否則節(jié)點一直存在于Zookeeper上

?(2)EPHEMERAL-臨時節(jié)點臨時節(jié)點的生命周期與客戶端會話綁定，一旦客戶端會話失效(客

戶端與zookeeper連接斷開不一定會話失效),那么這個客戶端創(chuàng)建的所有臨時節(jié)點都會被移

除。

?(3)PERSISTENT_SEQUENTIAL-持久順序節(jié)點基本特性同持久節(jié)點，只是增加了W酹屬性，節(jié)

點名后邊會追加一個由父節(jié)點維護的自增整型數字。

?(4)EPHEMERAL_SEQUENTIAL-臨時順序節(jié)點基本特性同臨時節(jié)點，增加了順序屬性，節(jié)點名

后邊會追加一個由父節(jié)點維護的自增整型數字。

ZookeeperWatcher機制-數據變更通知

?Zookeeper允許客戶端向服務端的某個Znode注冊一個Watcher監(jiān)聽，當服務端的一些指定事

件觸發(fā)了這個Watcher,服務端會向指定客戶端發(fā)送一個事件通知來實現分布式的通知功能，然

后客戶端根據Watcher通知狀態(tài)和事件類型做出業(yè)務上的改變。

?工作機制：

(1)客戶端注冊watcher

(2)服務端處理watcher

(3)客戶端回調watcher

Watcher特性總結

1.一次性無論是服務端還是客戶端，一旦一個Watcher被觸發(fā)，Zookeeper都會將其從相應的存

儲中移除。這樣的設計有效的減輕了服務端的壓力，不然對于更新非常頻繁的節(jié)點，服務端會不斷

的向客戶端發(fā)送事件通知，無論對于網絡還是服務端的壓力都非常大。

2.客戶端串行執(zhí)行客戶端Watcher回調的過程是一個串行同步的過程.

3.輕量3.1、Watcher通知非常簡單，只會告訴客戶端發(fā)生了事件，而不會說明事件的具體內容。

3.2、客戶端向服務端注冊Watcher的時候，并不會把客戶端真實的Watcher對象實體傳遞到服

務端，僅僅是在客戶端請求中使用boolean類型屬性進行了標記。

4.watcherevent異步發(fā)送watcher的通知事件從server發(fā)送到client是異步的，這就存在一個問

題，不同的客戶端和服務器之間通過socket進行通信，由于網絡延遲或其他因素導致客戶端在不

通的時刻監(jiān)聽到事件，由于Zookeeper本身提供了orderingguarantee,即客戶端監(jiān)聽事件后，

才會感知它所監(jiān)視znode發(fā)生了變化。所以我們使用Zookeeper不能期望能夠監(jiān)控到節(jié)點每次的

變化。Zookeeper只能保證最終的一致性，而無法保證強一致性。

5.注冊watchergetData、exists.getChildren

6.觸發(fā)watchercreate,delete,setData

7.當一個客戶端連接到一個新的服務器上時，watch將會被以任意會話事件觸發(fā)。當與一個服務器

失去連接的時候，是無法接收到watch的。而當client重新連接時，如果需要的話，所有先前注

冊過的watch,都會被重新注冊。通常這是完全透明的。只有在一個特殊情況下，watch可能會

丟失：對于一個未創(chuàng)建的znode的existwatch,如果在客戶端斷開連接期間被創(chuàng)建了，并且隨后

在客戶端連接上之前又刪除了，這種情況下，這個watch事件可能會被丟失。

客戶端注冊Watcher實現

?(1)調用getData()/getChildren()/exist()三個API,傳入Watcher對象

?(2)標記請求request,封裝Watcher至！|WatchRegistration

?(3)封裝成Packet對象，發(fā)服務端發(fā)送request

?(4)收到服務端響應后，將Watcher注冊到ZKWatcherManager中進行管理

?(5)請求返回，完成注冊。

服務端處理Watcher實現

1.服務端接收Watcher并存儲接收到客戶端請求，處理請求判斷是否需要注冊Watcher,需要的話

將數據節(jié)點的節(jié)點路徑和ServerCnxn(ServerCnxn代表一個客戶端和服務端的連接，實現了

Watcher的process接口，此時可以看成一個Watcher對象)存儲在WatcherManager的

WatchTable和watch2Paths中去。

2.Watcher觸發(fā)以服務端接收到setData()事務請求觸發(fā)NodeDataChanged事件為例：

2.1封裝WatchedEvent將通知狀態(tài)(SyncConnected)、事件類型(NodeDataChanged)以及

節(jié)點路徑封裝成一個WatchedEvent對象

2.2查詢Watcher從WatchTable中根據節(jié)點路徑查找Watcher

2.3沒找到；說明沒有客戶端在該數據節(jié)點上注冊過Watcher

2.4找至ij;提取并從WatchTable和Watch2Paths中刪除對應Watcher(從這里可以看出

Watcher在服務端是一次性的，觸發(fā)一次就失效了)

3.調用process方法來觸發(fā)Watcher這里process主要就是通過ServerCnxn對應的TCP連接發(fā)送

Watcher事件通知。

客戶端回調Watcher

?客戶端SendThread線程接收事件通知，交由EventThread線程回調Watcher。

?客戶端的Watcher機制同樣是一次性的，一旦被觸發(fā)后，該Watcher就失效了。

ACL權限控制機制

?UGO(User/Group/Others)

?目前在Linux/Unix文件系統(tǒng)中使用，也是使用最廣泛的權限控制方式。是一種粗粒度的文件系統(tǒng)

權限控制模式.

?ACL(AccessControlList)訪問控制列表

?包括三個方面：

?權限模式(Scheme)(1)IP:從IP地址粒度進行權限控制(2)Digest:最常用，用類似于

username:password的權限標識來進行權限配置，便于區(qū)分不同應用來進行權限控制(3)

World:最開放的權限控制方式，是一種特殊的digest模式，只有一個權限標識"worldanyone"

(4)Super:超級用戶

?授權對象授權對象指的是權限賦予的用戶或一個指定實體，例如IP地址或是機器燈。

?權限Permission(1)CREATE:數據節(jié)點創(chuàng)建權限，允許授權對象在該Znode下創(chuàng)建子節(jié)點

(2)DELETE:子節(jié)點刪除權限，允許授權對象刪除該數據節(jié)點的子節(jié)點(3)READ:數據節(jié)點

的讀取權限，允許授權對象訪問該數據節(jié)點并讀取其數據內容或子節(jié)點列表等(4)WRITE:數據

節(jié)點更新權限，允許授權對象對該數據節(jié)點進行更新操作(5)ADMIN:數據節(jié)點管理權限，允

許授權對象對該數據節(jié)點進行ACL相關設置操作

Chroot特性

?3.2.0版本后，添加了Chroot特性，該特性允許每個客戶端為自己設置一個命名空間。如果一個

客戶端設置了Chroot,那么該客戶端對服務器的任何操作，都將會被限制在其自己的命名空間

下。

?通過設置Chroot,能夠將一個客戶端應用于Zookeeper服務端的一顆子樹相對應，在那些多個應

用公用一個Zookeeper進群的場景下，對實現不同應用間的相互隔離非常有幫助。

會話管理

?分桶策略：將類似的會話放在同一區(qū)塊中進行管理，以便于Zookeeper對會話進行不同區(qū)塊的隔

離處理以及同一區(qū)塊的統(tǒng)一處理。

?分配原則：每個會話的"下次超時時間點"(ExpirationTime)

?計算公式：

ExpirationTime_=currentTime+sessionTimeout

ExpirationTime=(ExpirationTime_/Expirationlnrerval+1)*

Expirationinterval,Expirationinterval是指Zookeeper會話超時檢查時間間隔，默認tickTime

服務器角色

?Leader

(1)事務請求的唯一調度和處理者，保證集群事務處理的順序性

(2)集群內部各服務的調度者

?Follower

(1)處理客戶端的非事務請求，轉發(fā)事務請求給Leader服務器

(2)參與事務請求Proposal的投票

(3)參與Leader選舉投票

?Observer

(1)3.0版本以后引入的一個服務器角色，在不影響集群事務處理能力的基礎上提升集群的非事

務處理能力

(2)處理客戶端的非事務請求，轉發(fā)事務請求給Leader服務器

(3)不參與得可形式的投票

Zookeeper下Server工作狀態(tài)

?服務器具有四種狀態(tài)，分別是LOOKING、FOLLOWING,LEADING.OBSERVING,

(1)LOOKING:尋找Leader狀態(tài)。當服務器處于該狀態(tài)時，它會認為當前集群中沒有

Leader,因此需要進入Leader選舉狀態(tài).

(2)FOLLOWING:跟隨者狀態(tài)。表明當前服務器角色是Follower。

(3)LEADING:領導者狀態(tài)。表明當前服務器角色是Leader。

(4)OBSERVING:觀察者狀態(tài)。表明當前服務器角色是Observer。

數據同步

?整個集群完成Leader選舉之后，Learner(Follower和。bserver的統(tǒng)稱)回向Leader服務器進

行注冊。當Learner服務器想Leader服務器完成注冊后，進入數據同步環(huán)節(jié)。

?數據同步流程：(均以消息傳遞的方式進行)

oLearner向Learder注冊

。數據同步

。同步確認

?Zookeeper的數據同步通常分為四類：

(1)直接差異化同步(DIFF同步)

(2)先回滾再差異化同步(TRUNC+DIFF同步)

(3)僅回滾同步(TRUNC同步)

(4)全量同步(SNAP同步)

?在進行數據同步前，Leader服務器會完成數據同步初始化：

。peerLastZxid:從learner服務器注冊時發(fā)送的ACKEPOCH消息中提取出stZxid(該Learner

服務器最后處理的ZXID)

ominCommittedLog:Leader服務器Proposal緩存隊列committedLog中最小ZXID

maxCommittedLog:Leader服務器Proposal緩存隊列committedLog中最大ZXID

?直接差異化同步（DIFF同步）場景：peerLastZxid介于minCommittedLog和maxCommittedLog

之間

整個直接差異化同步過程中涉及的Leader和Learner之間的數據包通信如圖7?50所示。

?先回滾再差異化同步（TRUNC+DIFF同步）場景：當新的Leader服務器發(fā)現某個Learner服務器包

含了一條自己沒有的事務記錄，那么就需要讓該Learner服務器進行事務回滾--回滾到Leader服務

器上存在的,同時也是最接近于peerLastZxid的ZXID

?僅回滾同步（TRUNC同步）場景：peerLastZxid大于maxCommittedLog

?全量同步（SNAP同步）場景一：peerLastZxid小于minCommittedLog場景二：Leader服務器

上沒有Proposal緩存隊列且peerLastZxid不等于lastProcessZxid

zookeeper是如何保證事務的順序一致性的？

?zookeeper采用了全局遞增的事務Id來標識，所有的proposal（提議）都在被提出的時候加上了

zxid,zxid實際上是一個64位的數字，高32位是epoch（時期;紀元;世;新時代）用來標識

leader周期，如果有新的leader產生出來，epoch會自增，低32位用來遞增計數。當新產生

proposal的時候，會依據數據庫的兩階段過程，首先會向其他的server發(fā)出事務執(zhí)行請求，如果

超過半數的機器都能執(zhí)行并且能夠成功，那么就會開始執(zhí)行。

分布式集群中為什么會有Master主節(jié)點？

?在分布式環(huán)境中，有些業(yè)務邏輯只需要集群中的某一臺機器進行執(zhí)行，其他的機器可以共享這個結

果，這樣可以大大減少重復計算，提高性能，于是就需要進行l(wèi)eader選舉。

zk節(jié)點宕機如何處理？

?Zookeeper本身也是集群，推薦配置不少于3個服務器。Zookeeper自身也要保證當一個節(jié)點宕

機時，其他節(jié)點會繼續(xù)提供服務。

?如果是一個Follower宕機，還有2臺服務器提供訪問，因為Zookeeper上的數據是有多個副本

的，數據并不會丟失；

?如果是一個Leader宕機，Zookeeper會選舉出新的Leader.

?ZK集群的機制是只要超過半數的節(jié)點正常，集群就能正常提供服務。只有在ZK節(jié)點掛得太多，只

剩一半或不到一半節(jié)點能工作，集群才失效。

所以

?3個節(jié)點的cluster可以掛掉1個節(jié)點（leader可以得到2票＞1.5）

?2個節(jié)點的cluster就不能掛掉任何1個節(jié)點了（leader可以得到1票＜=1）

zookeeper負載均衡和nginx負載均衡區(qū)別

?Zk的負載均衡是可以調控，nginx只是能調權重，其他需要可控的都需要自己寫插件；但是nginx

的吞吐量比zk大很多，應該說按業(yè)務選擇用哪種方式。

Zookeeper有哪幾種幾種部署模式？

?Zookeeper有三種部署模式：

1.單機部署：一臺集群上運行；

2.集群部署：多臺集群運行；

3.偽集群部署：一臺集群啟動多個Zookeeper實例運行。

集群最少要幾臺機器，集群規(guī)則是怎樣的？集群中有3臺

服務器，其中一個節(jié)點宕機，這個時候Zookeeper還可以

使用嗎？

?集群規(guī)則為2N+1臺，N>0,即3臺?？梢岳^續(xù)使用，單數服務器只要沒超過一半的服務器宕機就

可以繼續(xù)使用.

集群支持動態(tài)添加機器嗎？

?其實就是水平擴容了，Zookeeper在這方面不太好。兩種方式：

?全部重啟：關閉所有Zookeeper服務，修改配置之后啟動。不影響之前客戶端的會話。

?逐個重啟：在過半存活即可用的原則下，一臺機器重啟不影響整個集群對外提供服務。這是比較常

用的方式。

?3.5版本開始支持動態(tài)擴容。

Zookeeper對節(jié)點的watch監(jiān)聽通知是永久的嗎？為什

么不是永久的？

?不是。官方聲明：一個Watch事件是一個一次性的觸發(fā)器，當被設置了Watch的數據發(fā)生了改變

的時候，則服務器將這個改變發(fā)送給設置了Watch的客戶端，以便通知它們。

?為什么不是永久的，舉個例子，如果服務端變動頻繁，而監(jiān)聽的客戶端很多情況下，每次變動都要

通知到所有的客戶端，給網絡和服務器造成很大壓力。

?一般是客戶端執(zhí)行getData（"/節(jié)點A”,true）,如果節(jié)點A發(fā)生了變更或刪除，客戶端會得到它的

watch事件，但是在之后節(jié)點A又發(fā)生了變更，而客戶端又沒有設置watch事件，就不再給客戶

?，八、丫

U而發(fā)送。

?在實際應用中，很多情況下，我們的客戶端不需要知道服務端的每一次變動，我只要最新的數據即

可。

Zookeeper的java客戶端都有哪些？

?java客戶端：zk自帶的zkclient及Apache開源的Curator。

chubby是什么，和zookeeper比你怎么看？

?chubby是google的，完全實現paxos算法，不開源。zookeeper是chubby的開源實現，使用

zab協(xié)議，paxos算法的變種。

說幾個zookeeper常用的命令。

?常用命令：Isgetsetcreatedelete等。

ZAB和Paxos算法的聯系與區(qū)別？

?相同點：

(1)兩者都存在一個類似于Leader進程的角色，由其負責協(xié)調多個Follower進程的運行

(2)Leader進程都會等待超過半數的Follower做出正確的反饋后，才會將一個提案進行提交

(3)ZAB協(xié)議中，每個Proposal中都包含一個epoch值來代表當前的Leader周期，Paxos中

名字為Ballot

?不同點：

ZAB用來構建高可用的分布式數據主備系統(tǒng)(Zookeeper),Paxos是用來構建分布式一致性狀

態(tài)機系統(tǒng)。

Zookeeper的典型應用場景

?Zookeeper是一個典型的發(fā)布/訂閱模式的分布式數據管理與協(xié)調框架，開發(fā)人員可以使用它來進

行分布式數據的發(fā)布和訂閱。

?通過對Zookeeper中豐富的數據節(jié)點進行交叉使用，配合Watcher事件通知機制，可以非常方便

的構建一系列分布式應用中年都會涉及的核心功能，如：

(1)數據發(fā)布/訂閱

(2)負載均衡

(3)命名服務

(4)分布式協(xié)調/通知

(5)集群管理

(6)Master選舉

(7)分布式鎖

(8)分布式隊列

1數據發(fā)布/訂閱

介紹

?數據發(fā)布/訂閱系統(tǒng)，即所謂的配置中心，顧名思義就是發(fā)布者發(fā)布數據供訂閱者進行數據訂閱。

目的

?動態(tài)獲取數據(配置信息)

?實現數據(配置信息)的集中式管理和數據的動態(tài)更新

設計模式

?Push模式

?Pull模式

數據(配置信息)特性

(1)數據量通常比較小(2)數據內容在運行時會發(fā)生動態(tài)更新(3)集群中各機器共享，配置一致

?如：機器列表信息、運行時開關配置、數據庫配置信息等

基于Zookeeper的實現方式

??數據存儲：將數據（配置信息）存儲到Zookeeper上的一個數據節(jié)點

??數據獲?。簯迷趩映跏蓟?jié)點從Zookeeper數據節(jié)點讀取數據，并在該節(jié)點上注冊一個數

據變更Watcher

??數據變更：當變更數據時，更新Zookeeper對應節(jié)點數據，Zookeeper會將數據變更通知發(fā)到

各客戶端，客戶端接到通知后重新讀取變更后的數據即可。

2負載均衡

?zk的命名服務

?命名服務是指通過指定的名字來獲取資源或者服務的地址，利用zk創(chuàng)建一個全局的路徑，這個路

徑就可以作為一個名字，指向集群中的集群，提供的服務的地址，或者一個遠程的對象等等.

分布式通知和協(xié)調

?對于系統(tǒng)調度來說：操作人員發(fā)送通知實際是通過控制臺改變某個節(jié)點的狀態(tài)，然后Zk將這些變

化發(fā)送給注冊了這個節(jié)點的watcher的所有客戶端。

?對于執(zhí)行情況匯報：每個工作進程都在某個目錄下創(chuàng)建一個臨時節(jié)點。并攜帶工作的進度數據，這

樣匯總的進程可以監(jiān)控目錄子節(jié)點的變化獲得工作進度的實時的全局情況。

zk的命名服務（文件系統(tǒng)）

?命名服務是指通過指定的名字來獲取資源或者服務的地址，利用zk創(chuàng)建一個全局的路徑，即是唯

一的路徑，這個路徑就可以作為一個名字，指向集群中的集群，提供的服務的地址，或者一個遠程

的對象等等。

zk的配置管理（文件系統(tǒng)、通知機制）

?程序分布式的部署在不同的機器上，將程序的配置信息放在zk的znode下，當有配置發(fā)生改變

時，也就是znode發(fā)生變化時，可以通過改變zk中某個目錄節(jié)點的內容，利用watcher通知給

各個客戶端，從而更改配置。

Zookeeper集群管理（文件系統(tǒng)、通知機制）

?所渭集群管理無在乎兩點：是否有機器退出和加入、選舉master。

?對于第一點，所有機器約定在父目錄下創(chuàng)建臨時目錄節(jié)點，然后監(jiān)聽父目錄節(jié)點

?的子節(jié)點變化消息。一旦有機器掛掉，該機器與zookeeper的連接斷開，其所創(chuàng)建的臨時目錄節(jié)

點被刪除，所有其他機器都收到通知：某個兄弟目錄被刪除，于是，所有人都知道：它上船了。

?新機器加入也是類似，所有機器收到通知：新兄弟目錄加入，highcount又有了，對于第二點，我

們稍微改變一下，所有機器創(chuàng)建臨時順序編號目錄節(jié)點，每次選取編號最小的機器作為master就

好。

Zookeeper分布式鎖（文件系統(tǒng)、通知機制）

?有了zookeeper的一致性文件系統(tǒng)，鎖的問題變得容易。鎖服務可以分為兩類，f是保持獨

占，另一個是控制時序。

?對于第一類，我們將zookeeper上的一個znode看作是一把鎖，通過createznode的方式來實

現。所有客戶端都去創(chuàng)建/distribute」ock節(jié)點，最終成功創(chuàng)建的那個客戶端也即擁有了這把鎖。

用完刪除掉自己創(chuàng)建的distributejock節(jié)點就釋放出鎖。

?對于第二類，/distributejock已經預先存在，所有客戶端在它下面創(chuàng)建臨時順序編號目錄節(jié)點，

和選master一樣，編號最小的獲得鎖，用完刪除，依次方便。

Zookeeper隊列管理（文件系統(tǒng)、通知機制）

?兩種類型的隊列：

（1）同步隊列，當一個隊列的成員都聚齊時，這個隊列才可用，否則一直等待所有成員到達。

（2）隊列按照FIFO方式進行入隊和出隊操作。

?第一類，在約定目錄下創(chuàng)建臨時目錄節(jié)點，監(jiān)聽節(jié)點數目是否是我們要求的數目。

?第二類，和分布式鎖服務中的控制時序場景基本原理一致，入列有編號，出列按編號。在特定的目

錄下創(chuàng)建PERSISTENT_SEQUENTIAL節(jié)點，創(chuàng)J建成功時Watcher通知等待的隊歹U,隊列刪除序列

號最小的節(jié)點用以消費。此場景下Zookeeper的znode用于消息存儲，znode存儲的數據就是消

息隊列中的消息內容，SEQUENTIAL序列號就是消息的編號，按序取出即可.由于創(chuàng)建的節(jié)點是

持久化的，所以不必擔心隊列消息的丟失問題。

Zookeeper都有哪些功能？

1.集群管理：監(jiān)控節(jié)點存活狀態(tài)、運行請求等；

2.主節(jié)點選舉：主節(jié)點掛掉了之后可以從備用的節(jié)點開始新一輪選主，主節(jié)點選舉說的就是這個選舉

的過程，使用Zoo