本篇內(nèi)容介紹了“Zookeeper面試常見的問題有哪些”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

創(chuàng)新互聯(lián)公司是一家專注于成都網(wǎng)站設計、成都做網(wǎng)站與策劃設計,莒縣網(wǎng)站建設哪家好?創(chuàng)新互聯(lián)公司做網(wǎng)站,專注于網(wǎng)站建設10年,網(wǎng)設計領域的專業(yè)建站公司;建站業(yè)務涵蓋:莒縣等地區(qū)。莒縣做網(wǎng)站價格咨詢:13518219792

NO1：說說zookeeper是什么?

ZooKeeper是一個分布式的，開放源碼的分布式應用程序協(xié)調(diào)服務，是Google的Chubby一個開源的實現(xiàn)(Chubby是不開源的)，它是集群的管理者，監(jiān)視著集群中各個節(jié)點的狀態(tài)根據(jù)節(jié)點提交的反饋進行下一步合理操作。最終，將簡單易用的接口和性能高效、功能穩(wěn)定的系統(tǒng)提供給用戶  。

Zookeeper一個最常用的使用場景就是用于擔任服務生產(chǎn)者和服務消費者的注冊中心，服務生產(chǎn)者將自己提供的服務注冊到Zookeeper中心，服務的消費者在進行服務調(diào)用的時候先到Zookeeper中查找服務，獲取到服務生產(chǎn)者的詳細信息之后，再去調(diào)用服務生產(chǎn)者的內(nèi)容與數(shù)據(jù)，簡單示例圖如下：

NO2：了解Zookeeper的系統(tǒng)架構嗎?

ZooKeeper 的架構圖中我們需要了解和掌握的主要有：

(1)ZooKeeper分為服務器端(Server) 和客戶端(Client)，客戶端可以連接到整個 ZooKeeper服務的任意服務器上(除非  leaderServes 參數(shù)被顯式設置， leader 不允許接受客戶端連接)。

(2)客戶端使用并維護一個 TCP 連接，通過這個連接發(fā)送請求、接受響應、獲取觀察的事件以及發(fā)送信息。如果這個 TCP  連接中斷，客戶端將自動嘗試連接到另外的 ZooKeeper服務器?？蛻舳说谝淮芜B接到 ZooKeeper服務時，可以接受這個連接的  ZooKeeper服務器會為這個客戶端建立一個會話。當這個客戶端連接到另外的服務器時，這個會話會被新的服務器重新建立。

(3)上圖中每一個Server代表一個安裝Zookeeper服務的機器，即是整個提供Zookeeper服務的集群(或者是由偽集群組成);

(4)組成ZooKeeper服務的服務器必須彼此了解。它們維護一個內(nèi)存中的狀態(tài)圖像，以及持久存儲中的事務日志和快照，  只要大多數(shù)服務器可用，ZooKeeper服務就可用;

(5)ZooKeeper 啟動時，將從實例中選舉一個 leader，Leader  負責處理數(shù)據(jù)更新等操作，一個更新操作成功的標志是當且僅當大多數(shù)Server在內(nèi)存中成功修改數(shù)據(jù)。每個Server 在內(nèi)存中存儲了一份數(shù)據(jù)。

(6)Zookeeper是可以集群復制的，集群間通過Zab協(xié)議(Zookeeper Atomic Broadcast)來保持數(shù)據(jù)的一致性;

(7)Zab協(xié)議包含兩個階段：leader election階段和Atomic Brodcast階段。

a)  集群中將選舉出一個leader，其他的機器則稱為follower，所有的寫操作都被傳送給leader，并通過brodcast將所有的更新告訴給follower。

b) 當leader崩潰或者leader失去大多數(shù)的follower時，需要重新選舉出一個新的leader，讓所有的服務器都恢復到一個正確的狀態(tài)。

c) 當leader被選舉出來，且大多數(shù)服務器完成了 和leader的狀態(tài)同步后，leadder election  的過程就結(jié)束了，就將會進入到Atomic brodcast的過程。

d) Atomic Brodcast同步leader和follower之間的信息，保證leader和follower具有形同的系統(tǒng)狀態(tài)。

NO3：能說說Zookeeper的工作原理?

Zookeeper的核心是原子廣播，這個機制保證了各個Server之間的同步。實現(xiàn)這個機制的協(xié)議叫做Zab協(xié)議。

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

Zab協(xié)議 的全稱是 Zookeeper Atomic Broadcast** (Zookeeper原子廣播)。Zookeeper 是通過 Zab  協(xié)議來保證分布式事務的最終一致性。Zab協(xié)議要求每個 Leader 都要經(jīng)歷三個階段：發(fā)現(xiàn)，同步，廣播。

當服務啟動或者在領導者崩潰后，Zab就進入了恢復模式，當領導者被選舉出來，且大多數(shù)Server完成了和  leader的狀態(tài)同步以后，恢復模式就結(jié)束了。狀態(tài)同步保證了leader和Server具有相同的系統(tǒng)狀態(tài)。

為了保證事務的順序一致性，zookeeper采用了遞增的事務id號(zxid)來標識事務。所有的提議(proposal)都在被提出的時候加  上了zxid。實現(xiàn)中zxid是一個64位的數(shù)字，它高32位是epoch用來標識leader關系是否改變，每次一個leader被選出來，它都會有一  個新的epoch，標識當前屬于那個leader的統(tǒng)治時期。第32位用于遞增計數(shù)。

epoch：可以理解為皇帝的年號，當新的皇帝leader產(chǎn)生后，將有一個新的epoch年號。

每個Server在工作過程中有三種狀態(tài)：

• LOOKING：當前Server不知道leader是誰，正在搜尋。

• LEADING：當前Server即為選舉出來的leader。

• FOLLOWING：leader已經(jīng)選舉出來，當前Server與之同步。

NO4：Zookeeper為什么要這么設計?

ZooKeeper設計的目的是提供高性能、高可用、順序一致性的分布式協(xié)調(diào)服務、保證數(shù)據(jù)最終一致性。

高性能(簡單的數(shù)據(jù)模型)

• 采用樹形結(jié)構組織數(shù)據(jù)節(jié)點;

• 全量數(shù)據(jù)節(jié)點，都存儲在內(nèi)存中;

• Follower 和 Observer 直接處理非事務請求;

高可用(構建集群)

• 半數(shù)以上機器存活，服務就能正常運行

• 自動進行 Leader 選舉

順序一致性(事務操作的順序)

• 每個事務請求，都會轉(zhuǎn)發(fā)給 Leader 處理

• 每個事務，會分配全局唯一的遞增id(zxid，64位：epoch + 自增 id)

最終一致性

• 通過提議投票方式，保證事務提交的可靠性

• 提議投票方式，只能保證 Client 收到事務提交成功后，半數(shù)以上節(jié)點能夠看到最新數(shù)據(jù)

NO5：你知道Zookeeper中有哪些角色?

系統(tǒng)模型：

領導者(leader)

Leader服務器為客戶端提供讀服務和寫服務。負責進行投票的發(fā)起和決議，更新系統(tǒng)狀態(tài)。

學習者(learner)

• 跟隨者(follower) Follower服務器為客戶端提供讀服務，參與Leader選舉過程，參與寫操作“過半寫成功”策略。

• 觀察者(observer)  Observer服務器為客戶端提供讀服務，不參與Leader選舉過程，不參與寫操作“過半寫成功”策略。用于在不影響寫性能的前提下提升集群的讀性能。

客戶端(client)：服務請求發(fā)起方。

NO6：你熟悉Zookeeper節(jié)點ZNode和相關屬性嗎?

節(jié)點有哪些類型?

Znode兩種類型：

• 持久的(persistent)：客戶端和服務器端斷開連接后，創(chuàng)建的節(jié)點不刪除(默認)。

• 短暫的(ephemeral)：客戶端和服務器端斷開連接后，創(chuàng)建的節(jié)點自己刪除。

Znode有四種形式：

• 持久化目錄節(jié)點(PERSISTENT)：客戶端與Zookeeper斷開連接后，該節(jié)點依舊存在持久化順序編號目錄節(jié)點(PERSISTENT_SEQUENTIAL)

• 客戶端與Zookeeper斷開連接后，該節(jié)點依舊存在，只是Zookeeper給該節(jié)點名稱進行順序編號：臨時目錄節(jié)點(EPHEMERAL)

• 客戶端與Zookeeper斷開連接后，該節(jié)點被刪除：臨時順序編號目錄節(jié)點(EPHEMERAL_SEQUENTIAL)

• 客戶端與Zookeeper斷開連接后，該節(jié)點被刪除，只是Zookeeper給該節(jié)點名稱進行順序編號

「注意」：創(chuàng)建ZNode時設置順序標識，ZNode名稱后會附加一個值，順序號是一個單調(diào)遞增的計數(shù)器，由父節(jié)點維護。

節(jié)點屬性有哪些

一個znode節(jié)點不僅可以存儲數(shù)據(jù)，還有一些其他特別的屬性。接下來我們創(chuàng)建一個/test節(jié)點分析一下它各個屬性的含義。

[zk: localhost:2181(CONNECTED) 6] get /test    456    cZxid = 0x59ac //    ctime = Mon Mar 30 15:20:08 CST 2020    mZxid = 0x59ad    mtime = Mon Mar 30 15:22:25 CST 2020    pZxid = 0x59ac    cversion = 0    dataVersion = 2    aclVersion = 0    ephemeralOwner = 0x0    dataLength = 3    numChildren = 0

屬性說明

NO7：請簡述Zookeeper的選主流程

Zookeeper的核心是原子廣播，這個機制保證了各個Server之間的同步。實現(xiàn)這個機制的協(xié)議叫做Zab協(xié)議。Zab協(xié)議有兩種模式，它們分別是恢復模式(選主)和廣播模式(同步)。當服務啟動或者在領導者崩潰后，Zab就進入了恢復模式，當領導者被選舉出來，且大多數(shù)Server完成了和leader的狀態(tài)同步以后，恢復模式就結(jié)束了。狀態(tài)同步保證了leader和Server具有相同的系統(tǒng)狀態(tài)。leader選舉是保證分布式數(shù)據(jù)一致性的關鍵。

出現(xiàn)選舉主要是兩種場景：初始化、leader不可用。

當zk集群中的一臺服務器出現(xiàn)以下兩種情況之一時，就會開始leader選舉。

• 服務器初始化啟動。

• 服務器運行期間無法和leader保持連接。

而當一臺機器進入leader選舉流程時，當前集群也可能處于以下兩種狀態(tài)。

• 集群中本來就已經(jīng)存在一個leader。

• 集群中確實不存在leader。

首先第一種情況，通常是集群中某一臺機器啟動比較晚，在它啟動之前，集群已經(jīng)正常工作，即已經(jīng)存在一臺leader服務器。當該機器試圖去選舉leader時，會被告知當前服務器的leader信息，它僅僅需要和leader機器建立連接，并進行狀態(tài)同步即可。

重點是leader不可用了，此時的選主制度。

投票信息中包含兩個最基本的信息。

• sid：即server id，用來標識該機器在集群中的機器序號。

• zxid：即zookeeper事務id號。

ZooKeeper狀態(tài)的每一次改變, 都對應著一個遞增的Transaction id,，該id稱為zxid.，由于zxid的遞增性質(zhì),  如果zxid1小于zxid2,，那么zxid1肯定先于zxid2發(fā)生。創(chuàng)建任意節(jié)點，或者更新任意節(jié)點的數(shù)據(jù)，  或者刪除任意節(jié)點，都會導致Zookeeper狀態(tài)發(fā)生改變，從而導致zxid的值增加。

以(sid，zxid)的形式來標識一次投票信息。

例如：如果當前服務器要推舉sid為1，zxid為8的服務器稱為leader，那么投票信息可以表示為(1，8)

集群中的每臺機器發(fā)出自己的投票后，也會接受來自集群中其他機器的投票。每臺機器都會根據(jù)一定的規(guī)則，來處理收到的其他機器的投票，以此來決定是否需要變更自己的投票。

規(guī)則如下：

• 初始階段，都會給自己投票。

• 當接收到來自其他服務器的投票時，都需要將別人的投票和自己的投票進行pk，規(guī)則如下：

優(yōu)先檢查zxid。zxid比較大的服務器優(yōu)先作為leader。如果zxid相同的話，就比較sid，sid比較大的服務器作為leader。

NO8：有了解過watch機制嗎?

簡單地說：client端會對某個znode  注冊一個watcher事件，當該znode發(fā)生變化時，這些client會收到ZooKeeper的通知，然后client可以根據(jù)znode變化來做出業(yè)務上的改變等。

經(jīng)典使用場景：zookeeper為dubbo提供服務的注冊與發(fā)現(xiàn)，作為注冊中心，但是大家有沒有想過zookeeper為啥能夠?qū)崿F(xiàn)服務的注冊與發(fā)現(xiàn)嗎?

這就不得不說一下zookeeper的靈魂 Watcher(監(jiān)聽者)。

什么是watcher?

watcher 是zooKeeper中一個非常核心功能 ，客戶端watcher  可以監(jiān)控節(jié)點的數(shù)據(jù)變化以及它子節(jié)點的變化，一旦這些狀態(tài)發(fā)生變化，zooKeeper服務端就會通知所有在這個節(jié)點上設置過watcher的客戶端  ，從而每個客戶端都很快感知，它所監(jiān)聽的節(jié)點狀態(tài)發(fā)生變化，而做出對應的邏輯處理。

簡單的介紹了一下watcher  ，那么我們來分析一下，zookeeper是如何實現(xiàn)服務的注冊與發(fā)現(xiàn)。zookeeper的服務注冊與發(fā)現(xiàn)，主要應用的是zookeeper的znode節(jié)點數(shù)據(jù)模型和watcher機制，大致的流程如下：

• 服務注冊：服務提供者(Provider)啟動時，會向zookeeper服務端注冊服務信息，也就是創(chuàng)建一個節(jié)點，例如：用戶注冊服務com.xxx.user.register，并在節(jié)點上存儲服務的相關數(shù)據(jù)(如服務提供者的ip地址、端口等)。

• 服務發(fā)現(xiàn)：服務消費者(Consumer)啟動時，根據(jù)自身配置的依賴服務信息，向zookeeper服務端獲取注冊的服務信息并設置watch監(jiān)聽，獲取到注冊的服務信息之后，將服務提供者的信息緩存在本地，并進行服務的調(diào)用。

• 服務通知：一旦服務提供者因某種原因宕機不再提供服務之后，客戶端與zookeeper服務端斷開連接，zookeeper服務端上服務提供者對應服務節(jié)點會被刪除(例如：用戶注冊服務com.xxx.user.register)，隨后zookeeper服務端會異步向所有消費用戶注冊服務com.xxx.user.register，且設置了watch監(jiān)聽的服務消費者發(fā)出節(jié)點被刪除的通知，消費者根據(jù)收到的通知拉取最新服務列表，更新本地緩存的服務列表。

上邊的過程就是zookeeper可以實現(xiàn)服務注冊與發(fā)現(xiàn)的大致原理。

watcher有哪些類型?

znode節(jié)點可以設置兩類watch，一種是DataWatches，基于znode節(jié)點的數(shù)據(jù)變更從而觸發(fā) watch  事件，觸發(fā)條件getData()、exists()、setData()、 create()。

另一種是Child Watches，基于znode的孩子節(jié)點發(fā)生變更觸發(fā)的watch事件，觸發(fā)條件 getChildren()、  create()。

而在調(diào)用 delete() 方法刪除znode時，則會同時觸發(fā)Data Watches和Child  Watches，如果被刪除的節(jié)點還有父節(jié)點，則父節(jié)點會觸發(fā)一個Child Watches。

watcher有什么特性?

watch對節(jié)點的監(jiān)聽事件是一次性的!客戶端在指定的節(jié)點設置了監(jiān)聽watch，一旦該節(jié)點數(shù)據(jù)發(fā)生變更通知一次客戶端后，客戶端對該節(jié)點的監(jiān)聽事件就失效了。

如果還要繼續(xù)監(jiān)聽這個節(jié)點，就需要我們在客戶端的監(jiān)聽回調(diào)中，再次對節(jié)點的監(jiān)聽watch事件設置為True。否則客戶端只能接收到一次該節(jié)點的變更通知。

NO9：那你說說Zookeeper有哪些應用場景?

數(shù)據(jù)發(fā)布與訂閱

發(fā)布與訂閱即所謂的配置管理，顧名思義就是將數(shù)據(jù)發(fā)布到ZooKeeper節(jié)點上，供訂閱者動態(tài)獲取數(shù)據(jù)，實現(xiàn)配置信息的集中式管理和動態(tài)更新。例如全局的配置信息，地址列表等就非常適合使用。

數(shù)據(jù)發(fā)布/訂閱的一個常見的場景是配置中心，發(fā)布者把數(shù)據(jù)發(fā)布到 ZooKeeper  的一個或一系列的節(jié)點上，供訂閱者進行數(shù)據(jù)訂閱，達到動態(tài)獲取數(shù)據(jù)的目的。

• 配置信息一般有幾個特點:

• 數(shù)據(jù)量小的KV

• 數(shù)據(jù)內(nèi)容在運行時會發(fā)生動態(tài)變化

• 集群機器共享，配置一致

ZooKeeper 采用的是推拉結(jié)合的方式。

• 推: 服務端會推給注冊了監(jiān)控節(jié)點的客戶端 Wathcer 事件通知

• 答: 客戶端獲得通知后，然后主動到服務端拉取最新的數(shù)據(jù)

命名服務

作為分布式命名服務，命名服務是指通過指定的名字來獲取資源或者服務的地址，利用ZooKeeper創(chuàng)建一個全局的路徑，這個路徑就可以作為一個名字，指向集群中的集群，提供的服務的地址，或者一個遠程的對象等等。

統(tǒng)一命名服務的命名結(jié)構圖如下所示：

1、在分布式環(huán)境下，經(jīng)常需要對應用/服務進行統(tǒng)一命名，便于識別不同服務。

類似于域名與IP之間對應關系，IP不容易記住，而域名容易記住。

通過名稱來獲取資源或服務的地址，提供者等信息。

2、按照層次結(jié)構組織服務/應用名稱。

可將服務名稱以及地址信息寫到ZooKeeper上，客戶端通過ZooKeeper獲取可用服務列表類。

配置管理

程序分布式的部署在不同的機器上，將程序的配置信息放在ZooKeeper的znode下，當有配置發(fā)生改變時，也就是znode發(fā)生變化時，可以通過改變zk中某個目錄節(jié)點的內(nèi)容，利用watch通知給各個客戶端  從而更改配置。

ZooKeeper配置管理結(jié)構圖如下所示：

1、分布式環(huán)境下，配置文件管理和同步是一個常見問題。

一個集群中，所有節(jié)點的配置信息是一致的，比如 Hadoop 集群。

對配置文件修改后，希望能夠快速同步到各個節(jié)點上。

2、配置管理可交由ZooKeeper實現(xiàn)。

可將配置信息寫入ZooKeeper上的一個Znode。

各個節(jié)點監(jiān)聽這個Znode。

一旦Znode中的數(shù)據(jù)被修改，ZooKeeper將通知各個節(jié)點。

集群管理

所謂集群管理就是：是否有機器退出和加入、選舉master。

集群管理主要指集群監(jiān)控和集群控制兩個方面。前者側(cè)重于集群運行時的狀態(tài)的收集，后者則是對集群進行操作與控制。開發(fā)和運維中，面對集群，經(jīng)常有如下需求:

• 希望知道集群中究竟有多少機器在工作

• 對集群中的每臺機器的運行時狀態(tài)進行數(shù)據(jù)收集

• 對集群中機器進行上下線的操作

集群管理結(jié)構圖如下所示：

• 分布式環(huán)境中，實時掌握每個節(jié)點的狀態(tài)是必要的，可根據(jù)節(jié)點實時狀態(tài)做出一些調(diào)整。

• 可交由ZooKeeper實現(xiàn)。

可將節(jié)點信息寫入ZooKeeper上的一個Znode。

監(jiān)聽這個Znode可獲取它的實時狀態(tài)變化。

3、典型應用

Hbase中Master狀態(tài)監(jiān)控與選舉。

利用ZooKeeper的強一致性，能夠保證在分布式高并發(fā)情況下節(jié)點創(chuàng)建的全局唯一性，即：同時有多個客戶端請求創(chuàng)建 /currentMaster  節(jié)點，最終一定只有一個客戶端請求能夠創(chuàng)建成功

分布式通知與協(xié)調(diào)

1、分布式環(huán)境中，經(jīng)常存在一個服務需要知道它所管理的子服務的狀態(tài)。

• a)NameNode需知道各個Datanode的狀態(tài)。

• b)JobTracker需知道各個TaskTracker的狀態(tài)。

2、心跳檢測機制可通過ZooKeeper來實現(xiàn)。

3、信息推送可由ZooKeeper來實現(xiàn)，ZooKeeper相當于一個發(fā)布/訂閱系統(tǒng)。

分布式鎖

處于不同節(jié)點上不同的服務，它們可能需要順序地訪問一些資源，這里需要一把分布式的鎖。

• 分布式鎖具有以下特性：寫鎖、讀鎖、時序鎖。

• 寫鎖：在zk上創(chuàng)建的一個臨時的無編號的節(jié)點。由于是無序編號，在創(chuàng)建時不會自動編號，導致只能客戶端有一個客戶端得到鎖，然后進行寫入。

• 讀鎖：在zk上創(chuàng)建一個臨時的有編號的節(jié)點，這樣即使下次有客戶端加入是同時創(chuàng)建相同的節(jié)點時，他也會自動編號，也可以獲得鎖對象，然后對其進行讀取。

• 時序鎖：在zk上創(chuàng)建的一個臨時的有編號的節(jié)點根據(jù)編號的大小控制鎖。

分布式隊列

分布式隊列分為兩種：

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

• a)一個job由多個task組成，只有所有任務完成后，job才運行完成。

• b)可為job創(chuàng)建一個/job目錄，然后在該目錄下，為每個完成的task創(chuàng)建一個臨時的Znode，一旦臨時節(jié)點數(shù)目達到task總數(shù)，則表明job運行完成。

2、隊列按照FIFO方式進行入隊和出隊操作，例如實現(xiàn)生產(chǎn)者和消費者模型。

NO10：知道監(jiān)聽器的原理嗎?

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術社區(qū)

2. 創(chuàng)建一個Main()線程。

3. 在Main()線程中創(chuàng)建兩個線程，一個負責網(wǎng)絡連接通信(connect)，一個負責監(jiān)聽(listener)。

4. 通過connect線程將注冊的監(jiān)聽事件發(fā)送給Zookeeper。

5. 將注冊的監(jiān)聽事件添加到Zookeeper的注冊監(jiān)聽器列表中。

6. Zookeeper監(jiān)聽到有數(shù)據(jù)或路徑發(fā)生變化時，把這條消息發(fā)送給Listener線程。

7. Listener線程內(nèi)部調(diào)用process()方法。

NO11：為什么Zookeeper集群的數(shù)目，一般為奇數(shù)個?

首先需要明確zookeeper選舉的規(guī)則：leader選舉，要求可用節(jié)點數(shù)量 > 總節(jié)點數(shù)量/2。

比如：標記一個寫是否成功是要在超過一半節(jié)點發(fā)送寫請求成功時才認為有效。同樣，Zookeeper選擇領導者節(jié)點也是在超過一半節(jié)點同意時才有效。最后，Zookeeper是否正常是要根據(jù)是否超過一半的節(jié)點正常才算正常。這是基于CAP的一致性原理。

zookeeper有這樣一個特性：集群中只要有過半的機器是正常工作的，那么整個集群對外就是可用的。

也就是說如果有2個zookeeper，那么只要有1個死了zookeeper就不能用了，因為1沒有過半，所以2個zookeeper的死亡容忍度為0;

同理，要是有3個zookeeper，一個死了，還剩下2個正常的，過半了，所以3個zookeeper的容忍度為1;

同理：

• 2->0;兩個zookeeper，最多0個zookeeper可以不可用。

• 3->1;三個zookeeper，最多1個zookeeper可以不可用。

• 4->1;四個zookeeper，最多1個zookeeper可以不可用。

• 5->2;五個zookeeper，最多2個zookeeper可以不可用。

• 6->2;兩個zookeeper，最多0個zookeeper可以不可用。

• ....

會發(fā)現(xiàn)一個規(guī)律，2n和2n-1的容忍度是一樣的，都是n-1，所以為了更加高效，何必增加那一個不必要的zookeeper呢。

zookeeper的選舉策略也是需要半數(shù)以上的節(jié)點同意才能當選leader，如果是偶數(shù)節(jié)點可能導致票數(shù)相同的情況。

“Zookeeper面試常見的問題有哪些”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關的知識可以關注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！