JAVA面試寶典，搞定JAVA面試，不再是難題，系列文章傳送地址，請點(diǎn)擊本鏈接。

目錄

1、說說 Zookeeper 是什么？

2、ZooKeeper 有哪些應(yīng)用場景？

3、說說Zookeeper的工作原理？

4、請描述一下 Zookeeper 的通知機(jī)制是什么？

5、Zookeeper 對節(jié)點(diǎn)的 watch 監(jiān)聽通知是永久的嗎？

6、 Zookeeper 集群中有哪些角色？

7、 Zookeeper 集群中是怎樣選舉leader的？

8、 Zookeeper 是如何保證事務(wù)的順序一致性的呢？

9、 ZooKeeper 集群中個服務(wù)器之間是怎樣通信的？

10、ZooKeeper 分布式鎖怎么實(shí)現(xiàn)的？

11、了解Zookeeper的系統(tǒng)架構(gòu)嗎？

12、你熟悉Zookeeper節(jié)點(diǎn)ZNode和相關(guān)屬性嗎？

13、為什么Zookeeper集群的數(shù)目，一般為奇數(shù)個？

14、知道Zookeeper監(jiān)聽器的原理嗎？

15、說說 Zookeeper 的 CAP 問題上做的取舍？

16、說說Zookeeper中的腦裂？

17、Zookeeper腦裂是什么原因?qū)е碌模?/p>

18、Zookeeper 是如何解決腦裂問題的？

19、Zookeeper選舉中投票信息的五元組是什么？

20、講解一下 ZooKeeper 的持久化機(jī)制

21、在Zookeeper中Zxid和Epoch是什么，有什么作用？

22、ZooKeeper 負(fù)載均衡和 Nginx 負(fù)載均衡有什么區(qū)別？

24、說說Zookeeper中的ACL 權(quán)限控制機(jī)制

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

26、描述一下 ZAB 協(xié)議

27、ZAB 和 Paxos 算法的聯(lián)系與區(qū)別？

28、Zookeeper集群支持動態(tài)添加機(jī)器嗎？

1、說說 Zookeeper 是什么？

直譯：從名字上直譯就是動物管理員，動物指的是 Hadoop 一類的分布式軟件，管理員三個字體現(xiàn)
了 ZooKeeper 的特點(diǎn)：維護(hù)、協(xié)調(diào)、管理、監(jiān)控。
簡述：有些軟件你想做成集群或者分布式，你可以用 ZooKeeper 幫你來輔助實(shí)現(xiàn)。
特點(diǎn)：
最終一致性：客戶端看到的數(shù)據(jù)最終是一致的。
可靠性：服務(wù)器保存了消息，那么它就一直都存在。
實(shí)時性：ZooKeeper 不能保證兩個客戶端同時得到剛更新的數(shù)據(jù)。
獨(dú)立性（等待無關(guān)）：不同客戶端直接互不影響。
原子性：更新要不成功要不失敗，沒有第三個狀態(tài)。
注意：回答面試題，切忌只是簡單一句話回答，可以將你對概念的理解，特點(diǎn)等多個方面描述一
下，哪怕你自己認(rèn)為不完全切中題意的也可以說說，面試官不喜歡會打斷你的，你的目的是讓面試
官認(rèn)為你是好溝通的。當(dāng)然了，如果不會可別裝作會，說太多不專業(yè)的想法。

2、ZooKeeper 有哪些應(yīng)用場景？

A、數(shù)據(jù)發(fā)布與訂閱
?發(fā)布與訂閱即所謂的配置管理，顧名思義就是將數(shù)據(jù)發(fā)布到ZooKeeper節(jié)點(diǎn)上，供訂閱者動態(tài)獲取
數(shù)據(jù)，實(shí)現(xiàn)配置信息的集中式管理和動態(tài)更新。例如全局的配置信息，地址列表等就非常適合使
用。
數(shù)據(jù)發(fā)布/訂閱的一個常見的場景是配置中心，發(fā)布者把數(shù)據(jù)發(fā)布到 ZooKeeper 的一個或一系列的
節(jié)點(diǎn)上，供訂閱者進(jìn)行數(shù)據(jù)訂閱，達(dá)到動態(tài)獲取數(shù)據(jù)的目的。
配置信息一般有幾個特點(diǎn):
1. 數(shù)據(jù)量小的KV
2. 數(shù)據(jù)內(nèi)容在運(yùn)行時會發(fā)生動態(tài)變化
3. 集群機(jī)器共享，配置一致
ZooKeeper 采用的是推拉結(jié)合的方式。
1. 推: 服務(wù)端會推給注冊了監(jiān)控節(jié)點(diǎn)的客戶端 Wathcer 事件通知
2. 拉: 客戶端獲得通知后，然后主動到服務(wù)端拉取最新的數(shù)據(jù)

B、命名服務(wù)
?????? 作為分布式命名服務(wù)，命名服務(wù)是指通過指定的名字來獲取資源或者服務(wù)的地址，利用ZooKeeper創(chuàng)建一個全局的路徑，這個路徑就可以作為一個名字，指向集群中的集群，提供的服務(wù)的地址，或者一個遠(yuǎn)程的對象等等。統(tǒng)一命名服務(wù)的命名結(jié)構(gòu)圖如下所示：
1、在分布式環(huán)境下，經(jīng)常需要對應(yīng)用/服務(wù)進(jìn)行統(tǒng)一命名，便于識別不同服務(wù)。類似于域名與IP之間對應(yīng)關(guān)系，IP不容易記住，而域名容易記住。通過名稱來獲取資源或服務(wù)的地址，提供者等信息。
2、按照層次結(jié)構(gòu)組織服務(wù)/應(yīng)用名稱?？蓪⒎?wù)名稱以及地址信息寫到ZooKeeper上，客戶端通過ZooKeeper獲取可用服務(wù)列表類。

C、集群管理
所謂集群管理就是：是否有機(jī)器退出和加入、選舉master。
集群管理主要指集群監(jiān)控和集群控制兩個方面。前者側(cè)重于集群運(yùn)行時的狀態(tài)的收集，后者則是對
集群進(jìn)行操作與控制。開發(fā)和運(yùn)維中，面對集群，經(jīng)常有如下需求:
1. 希望知道集群中究竟有多少機(jī)器在工作
2. 對集群中的每臺機(jī)器的運(yùn)行時狀態(tài)進(jìn)行數(shù)據(jù)收集
3. 對集群中機(jī)器進(jìn)行上下線的操作
集群管理結(jié)構(gòu)圖如下所示：

1、分布式環(huán)境中，實(shí)時掌握每個節(jié)點(diǎn)的狀態(tài)是必要的，可根據(jù)節(jié)點(diǎn)實(shí)時狀態(tài)做出一些調(diào)整。
2、可交由ZooKeeper實(shí)現(xiàn)。
可將節(jié)點(diǎn)信息寫入ZooKeeper上的一個Znode。
監(jiān)聽這個Znode可獲取它的實(shí)時狀態(tài)變化。
3、典型應(yīng)用
Hbase中Master狀態(tài)監(jiān)控與選舉。
利用ZooKeeper的強(qiáng)一致性，能夠保證在分布式高并發(fā)情況下節(jié)點(diǎn)創(chuàng)建的全局唯一性，即：同時有
多個客戶端請求創(chuàng)建 /currentMaster 節(jié)點(diǎn)，最終一定只有一個客戶端請求能夠創(chuàng)建成功
D、分布式通知與協(xié)調(diào)
1、分布式環(huán)境中，經(jīng)常存在一個服務(wù)需要知道它所管理的子服務(wù)的狀態(tài)。
a）NameNode需知道各個Datanode的狀態(tài)。
b）JobTracker需知道各個TaskTracker的狀態(tài)。
2、心跳檢測機(jī)制可通過ZooKeeper來實(shí)現(xiàn)。
3、信息推送可由ZooKeeper來實(shí)現(xiàn)，ZooKeeper相當(dāng)于一個發(fā)布/訂閱系統(tǒng)。
E、分布式鎖
處于不同節(jié)點(diǎn)上不同的服務(wù)，它們可能需要順序的訪問一些資源，這里需要一把分布式的鎖。
分布式鎖具有以下特性：寫鎖、讀鎖、時序鎖。
寫鎖：在zk上創(chuàng)建的一個臨時的無編號的節(jié)點(diǎn)。由于是無序編號，在創(chuàng)建時不會自動編號，導(dǎo)致只
能客戶端有一個客戶端得到鎖，然后進(jìn)行寫入。
讀鎖：在zk上創(chuàng)建一個臨時的有編號的節(jié)點(diǎn)，這樣即使下次有客戶端加入是同時創(chuàng)建相同的節(jié)點(diǎn)
時，他也會自動編號，也可以獲得鎖對象，然后對其進(jìn)行讀取。
時序鎖：在zk上創(chuàng)建的一個臨時的有編號的節(jié)點(diǎn)根據(jù)編號的大小控制鎖。
?

F、分布式隊(duì)列
分布式隊(duì)列分為兩種：
1、當(dāng)一個隊(duì)列的成員都聚齊時，這個隊(duì)列才可用，否則一直等待所有成員到達(dá)，這種是同步隊(duì)
列。
a）一個job由多個task組成，只有所有任務(wù)完成后，job才運(yùn)行完成。
b）可為job創(chuàng)建一個/job目錄，然后在該目錄下，為每個完成的task創(chuàng)建一個臨時的Znode，一旦
臨時節(jié)點(diǎn)數(shù)目達(dá)到task總數(shù)，則表明job運(yùn)行完成。
2、隊(duì)列按照FIFO方式進(jìn)行入隊(duì)和出隊(duì)操作，例如實(shí)現(xiàn)生產(chǎn)者和消費(fèi)者模型。?

3、說說Zookeeper的工作原理？

Zookeeper的核心是原子廣播，這個機(jī)制保證了各個Server之間的同步。實(shí)現(xiàn)這個機(jī)制的協(xié)議叫做Zab協(xié)議。Zab協(xié)議有兩種模式，它們分別是恢復(fù)模式（選主）和廣播模式（同步）。Zab協(xié)議 的全稱是 Zookeeper Atomic Broadcast** （Zookeeper原子廣播）。Zookeeper 是通過Zab 協(xié)議來保證分布式事務(wù)的最終一致性。Zab協(xié)議要求每個 Leader 都要經(jīng)歷三個階段：發(fā)現(xiàn)，同步，廣播。

當(dāng)服務(wù)啟動或者在領(lǐng)導(dǎo)者崩潰后，Zab就進(jìn)入了恢復(fù)模式，當(dāng)領(lǐng)導(dǎo)者被選舉出來，且大多數(shù)Server完成了和 leader的狀態(tài)同步以后，恢復(fù)模式就結(jié)束了。狀態(tài)同步保證了leader和Server具有相同的系統(tǒng)狀態(tài)。為了保證事務(wù)的順序一致性，zookeeper采用了遞增的事務(wù)id號（zxid）來標(biāo)識事務(wù)。所有的提議（proposal）都在被提出的時候加 上了zxid。實(shí)現(xiàn)中zxid是一個64位的數(shù)字，它高32位是epoch用來標(biāo)識leader關(guān)系是否改變，每次一個leader被選出來，它都會有一 個新的epoch，標(biāo)識當(dāng)前屬于那個leader的統(tǒng)治時期。低32位用于遞增計(jì)數(shù)。

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

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

LOOKING：當(dāng)前Server不知道leader是誰，正在搜尋。

LEADING：當(dāng)前Server即為選舉出來的leader。

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

OBSERVING：觀察者狀態(tài)；表明當(dāng)前服務(wù)器角色是 Observer

4、請描述一下 Zookeeper 的通知機(jī)制是什么？

Zookeeper 允許客戶端向服務(wù)端的某個 znode 注冊一個 Watcher 監(jiān)聽，當(dāng)服務(wù)端的一些指定事件，觸發(fā)了這個 Watcher ，服務(wù)端會向指定客戶端發(fā)送一個事件通知來實(shí)現(xiàn)分布式的通知功能，然后客戶端根據(jù) Watcher 通知狀態(tài)和事件類型做出業(yè)務(wù)上的改變。大致分為三個步驟：

客戶端注冊 Watcher

1、調(diào)用 getData、getChildren、exist 三個 API ，傳入Watcher 對象。

2、標(biāo)記請求request ，封裝 Watcher 到 WatchRegistration 。

3、封裝成 Packet 對象，發(fā)服務(wù)端發(fā)送request 。

4、收到服務(wù)端響應(yīng)后，將 Watcher 注冊到 ZKWatcherManager 中進(jìn)行管理。

5、請求返回，完成注冊。

服務(wù)端處理 Watcher

1、服務(wù)端接收 Watcher 并存儲。

2、Watcher 觸發(fā)

3、調(diào)用 process 方法來觸發(fā) Watcher 。

客戶端回調(diào) Watcher

1，客戶端 SendThread 線程接收事件通知，交由 EventThread 線程回調(diào)Watcher 。

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

5、Zookeeper 對節(jié)點(diǎn)的 watch 監(jiān)聽通知是永久的嗎？

不是，一次性的。無論是服務(wù)端還是客戶端，一旦一個 Watcher 被觸發(fā)， Zookeeper 都會將其從相應(yīng)的存儲中移除。這樣的設(shè)計(jì)有效的減輕了服務(wù)端的壓力，不然對于更新非常頻繁的節(jié)點(diǎn)，服務(wù)端會不斷的向客戶端發(fā)送事件通知，無論對于網(wǎng)絡(luò)還是服務(wù)端的壓力都非常大。

6、 Zookeeper 集群中有哪些角色？

在一個集群中，最少需要 3 臺?；蛘弑ＷC 2N + 1 臺，即奇數(shù)。為什么保證奇數(shù)？主要是為了舉算法。

7、 Zookeeper 集群中是怎樣選舉leader的？

流程：

開始投票 -> 節(jié)點(diǎn)狀態(tài)變成 LOOKING -> 每個節(jié)點(diǎn)選自己-> 收到票進(jìn)行 PK -> sid 大的獲勝 -> 更新選票 -> 再次投票 -> 統(tǒng)計(jì)選票，選票過半數(shù)選舉結(jié)果 -> 節(jié)點(diǎn)狀態(tài)更新為自己的角色狀態(tài)。

當(dāng)Leader崩潰了，或者失去了大多數(shù)的Follower，這時候 Zookeeper 就進(jìn)入恢復(fù)模式，恢復(fù)模式需要重新選舉出一個新的Leader，讓所有的Server都恢復(fù)到一個狀態(tài)LOOKING 。Zookeeper 有兩種選舉算法：基于 basic paxos 實(shí)現(xiàn)和基于 fast paxos 實(shí)現(xiàn)。默認(rèn)為 fast paxos由于篇幅問題，這里推薦： zookeeper選舉

8、 Zookeeper 是如何保證事務(wù)的順序一致性的呢？

Zookeeper 采用了遞增的事務(wù) id 來識別，所有的 proposal （提議）都在被提出的時候加上了zxid 。 zxid 實(shí)際上是一個 64 位數(shù)字。高 32 位是 epoch 用來標(biāo)識 Leader 是否發(fā)生了改變，如果有新的Leader 產(chǎn)生出來， epoch 會自增。 低 32 位用來遞增計(jì)數(shù)。 當(dāng)新產(chǎn)生的 proposal 的時候，會依據(jù)數(shù)據(jù)庫的兩階段過程，首先會向其他的 Server 發(fā)出事務(wù)執(zhí)行請求，如果超過半數(shù)的機(jī)器都能執(zhí)行并且能夠成功，那么就會開始執(zhí)行。

9、 ZooKeeper 集群中個服務(wù)器之間是怎樣通信的？

Leader 服務(wù)器會和每一個 Follower/Observer 服務(wù)器都建立 TCP 連接，同時為每個Follower/Observer 都創(chuàng)建一個叫做 LearnerHandler 的實(shí)體。LearnerHandler 主要負(fù)責(zé) Leader 和Follower/Observer 之間的網(wǎng)絡(luò)通訊，包括數(shù)據(jù)同步，請求轉(zhuǎn)發(fā)和 proposal 提議的投票等。Leader 服務(wù)器保存了所有 Follower/Observer 的 LearnerHandler 。

10、ZooKeeper 分布式鎖怎么實(shí)現(xiàn)的？

如果有客戶端1、客戶端2等N個客戶端爭搶一個 Zookeeper 分布式鎖。大致如下：

1. 大家都是上來直接創(chuàng)建一個鎖節(jié)點(diǎn)下的一個接一個的臨時有序節(jié)點(diǎn)
2. 如果自己不是第一個節(jié)點(diǎn)，就對自己上一個節(jié)點(diǎn)加監(jiān)聽器
3. 只要上一個節(jié)點(diǎn)釋放鎖，自己就排到前面去了，相當(dāng)于是一個排隊(duì)機(jī)制。而且用臨時順序節(jié)的

另外一個用意就是，如果某個客戶端創(chuàng)建臨時順序節(jié)點(diǎn)之后，不小心自己宕機(jī)了也沒關(guān)系，Zookeeper 感知到那個客戶端宕機(jī)，會自動刪除對應(yīng)的臨時順序節(jié)點(diǎn)，相當(dāng)于自動釋放鎖，或者是自動取消自己的排隊(duì)。

本地鎖，可以用 JDK 實(shí)現(xiàn)，但是分布式鎖就必須要用到分布式的組件。比如 ZooKeeper、Redis。

網(wǎng)上代碼一大段，面試一般也不要寫，我這說一些關(guān)鍵點(diǎn)。幾個需要注意的地方如下。

死鎖問題：鎖不能因?yàn)橐馔饩妥兂伤梨i，所以要用 ZK 的臨時節(jié)點(diǎn)，客戶端連接失效了，鎖就自動釋放了。
鎖等待問題：鎖有排隊(duì)的需求，所以要 ZK 的順序節(jié)點(diǎn)。
鎖管理問題：一個使用釋放了鎖，需要通知其他使用者，所以需要用到監(jiān)聽。

監(jiān)聽的羊群效應(yīng)：比如有 1000 個鎖競爭者，鎖釋放了，1000 個競爭者就得到了通知，然后判斷，最終序號最小的那個拿到了鎖。其它 999 個競爭者重新注冊監(jiān)聽。這就是羊群效應(yīng)，出點(diǎn)事，就會驚動整個羊群。應(yīng)該每個競爭者只監(jiān)聽自己前面的那個節(jié)點(diǎn)。比如 2 號釋放了鎖，那么只有 3 號得到了通知。

11、了解Zookeeper的系統(tǒng)架構(gòu)嗎？

ZooKeeper 的架構(gòu)圖中我們需要了解和掌握的主要有：

（1）ZooKeeper分為服務(wù)器端（Server） 和客戶端（Client），客戶端可以連接到整個ZooKeeper服務(wù)的任意服務(wù)器上（除非 leaderServes 參數(shù)被顯式設(shè)置， leader 不允許接受客戶端連接）。
（2）客戶端使用并維護(hù)一個 TCP 連接，通過這個連接發(fā)送請求、接受響應(yīng)、獲取觀察的事件以及發(fā)送心跳。如果這個 TCP 連接中斷，客戶端將自動嘗試連接到另外的 ZooKeeper服務(wù)器。客戶端第一次連接到 ZooKeeper服務(wù)時，接受這個連接的 ZooKeeper服務(wù)器會為這個客戶端建立一個會話。當(dāng)這個客戶端連接到另外的服務(wù)器時，這個會話會被新的服務(wù)器重新建立。
（3）上圖中每一個Server代表一個安裝Zookeeper服務(wù)的機(jī)器，即是整個提供Zookeeper服務(wù)的集群（或者是由偽集群組成）；

（4）組成ZooKeeper服務(wù)的服務(wù)器必須彼此了解。它們維護(hù)一個內(nèi)存中的狀態(tài)圖像，以及持久存儲中的事務(wù)日志和快照， 只要大多數(shù)服務(wù)器可用，ZooKeeper服務(wù)就可用；
（5）ZooKeeper 啟動時，將從實(shí)例中選舉一個 leader，Leader 負(fù)責(zé)處理數(shù)據(jù)更新等操作，一個更新操作成功的標(biāo)志是當(dāng)且僅當(dāng)大多數(shù)Server在內(nèi)存中成功修改數(shù)據(jù)。每個Server 在內(nèi)存中存儲了一份數(shù)據(jù)。
（6）Zookeeper是可以集群復(fù)制的，集群間通過Zab協(xié)議（Zookeeper Atomic Broadcast）來保持?jǐn)?shù)據(jù)的一致性；
（7）Zab協(xié)議包含兩個階段：leader election階段和Atomic Brodcast階段。

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

b) 當(dāng)leader崩潰或者leader失去大多數(shù)的follower時，需要重新選舉出一個新的leader，讓所有的服務(wù)器都恢復(fù)到一個正確的狀態(tài)。
c) 當(dāng)leader被選舉出來，且大多數(shù)服務(wù)器完成了 和leader的狀態(tài)同步后，leadder election 的過程就結(jié)束了，就將會進(jìn)入到Atomic brodcast的過程。
d) Atomic Brodcast同步leader和follower之間的信息，保證leader和follower具有形同的系統(tǒng)狀態(tài)。

12、你熟悉Zookeeper節(jié)點(diǎn)ZNode和相關(guān)屬性嗎？

節(jié)點(diǎn)有哪些類型？

Znode兩種類型 ：

持久的（persistent）：客戶端和服務(wù)器端斷開連接后，創(chuàng)建的節(jié)點(diǎn)不刪除（默認(rèn)）。

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

Znode有四種形式 ：

1、持久化目錄節(jié)點(diǎn)（PERSISTENT）：客戶端與Zookeeper斷開連接后，該節(jié)點(diǎn)依舊存在

2、持久化順序編號目錄節(jié)點(diǎn)（PERSISTENT_SEQUENTIAL）：客戶端與Zookeeper斷開連接后，該節(jié)點(diǎn)依舊存在，只是Zookeeper給該節(jié)點(diǎn)名稱進(jìn)行順序編號：

3、臨時目錄節(jié)點(diǎn)（EPHEMERAL）：客戶端與Zookeeper斷開連接后，該節(jié)點(diǎn)被刪除

4、臨時順序編號目錄節(jié)點(diǎn)（EPHEMERAL_SEQUENTIAL）：客戶端與Zookeeper斷開連接后，該節(jié)點(diǎn)被刪除，只是Zookeeper給該節(jié)點(diǎn)名稱進(jìn)行順序編號

節(jié)點(diǎn)屬性有哪些？

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

一下它各個屬性的含義。

屬性說明

13、為什么Zookeeper集群的數(shù)目，一般為奇數(shù)個？

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

比如：標(biāo)記一個寫是否成功是要在超過一半節(jié)點(diǎn)發(fā)送寫請求成功時才認(rèn)為有效。同樣，Zookeeper

選擇領(lǐng)導(dǎo)者節(jié)點(diǎn)也是在超過一半節(jié)點(diǎn)同意時才有效。最后，Zookeeper是否正常是要根據(jù)是否超過

一半的節(jié)點(diǎn)正常才算正常。這是基于CAP的一致性原理。

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

的。也就是說如果有2個zookeeper，那么只要有1個死了zookeeper就不能用了，因?yàn)?沒有過半，所以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é)點(diǎn)同意才能當(dāng)選leader，如果是偶數(shù)節(jié)點(diǎn)可能導(dǎo)致票數(shù)相同的情況

14、知道Zookeeper監(jiān)聽器的原理嗎？

1. 創(chuàng)建一個Main()線程。
2. 在Main()線程中創(chuàng)建兩個線程，一個負(fù)責(zé)網(wǎng)絡(luò)連接通信（connect），一個負(fù)責(zé)監(jiān)聽（listener）。
3. 通過connect線程將注冊的監(jiān)聽事件發(fā)送給Zookeeper。
4. 將注冊的監(jiān)聽事件添加到Zookeeper的注冊監(jiān)聽器列表中。
5. Zookeeper監(jiān)聽到有數(shù)據(jù)或路徑發(fā)生變化時，把這條消息發(fā)送給Listener線程。
6. Listener線程內(nèi)部調(diào)用process()方法

15、說說 Zookeeper 的 CAP 問題上做的取舍？

一致性 C：Zookeeper 是強(qiáng)一致性系統(tǒng)，為了保證較強(qiáng)的可用性，“一半以上成功即成功”的數(shù)據(jù)同步方式可能會導(dǎo)致部分節(jié)點(diǎn)的數(shù)據(jù)不一致。所以 Zookeeper 還提供了 sync() 操作來做所有節(jié)點(diǎn)的數(shù)據(jù)同步，這就關(guān)于 C 和 A 的選擇問題交給了用戶，因?yàn)槭褂?sync()勢必會延長同步時間，可用性會有一些損失。

可用性 A：Zookeeper 數(shù)據(jù)存儲在內(nèi)存中，且各個節(jié)點(diǎn)都可以相應(yīng)讀請求，具有好的響應(yīng)性能。Zookeeper 保證了數(shù)據(jù)總是可用的，沒有鎖。并且有一大半的節(jié)點(diǎn)所擁有的數(shù)據(jù)是最新的。
分區(qū)容忍性 P：Follower 節(jié)點(diǎn)過多會導(dǎo)致增大數(shù)據(jù)同步的延時（需要半數(shù)以上 follower 寫完提交）。同時選舉過程的收斂速度會變慢，可用性降低。Zookeeper 通過引入 observer 節(jié)點(diǎn)緩解了這個問題，增加 observer 節(jié)點(diǎn)后集群可接受 client 請求的節(jié)點(diǎn)多了，而且 observer 不參與投票，可以提高可用性和擴(kuò)展性，但是節(jié)點(diǎn)多數(shù)據(jù)同步總歸是個問題，所以一致性會有所降低。

16、說說Zookeeper中的腦裂？

簡單點(diǎn)來說，腦裂(Split-Brain) 就是比如當(dāng)你的 cluster 里面有兩個節(jié)點(diǎn)，它們都知道在這個
cluster 里需要選舉出一個 master。那么當(dāng)它們兩個之間的通信完全沒有問題的時候，就會達(dá)成共識，選出其中一個作為 master。但是如果它們之間的通信出了問題，那么兩個結(jié)點(diǎn)都會覺得現(xiàn)在沒有 master，所以每個都把自己選舉成 master，于是 cluster 里面就會有兩個 master。對于Zookeeper來說有一個很重要的問題，就是到底是根據(jù)一個什么樣的情況來判斷一個節(jié)點(diǎn)死亡down掉了？在分布式系統(tǒng)中這些都是有監(jiān)控者來判斷的，但是監(jiān)控者也很難判定其他的節(jié)點(diǎn)的狀態(tài)，唯一一個可靠的途徑就是心跳，Zookeeper也是使用心跳來判斷客戶端是否仍然活著。使用ZooKeeper來做Leader HA基本都是同樣的方式：每個節(jié)點(diǎn)都嘗試注冊一個象征leader的臨時節(jié)點(diǎn)，其他沒有注冊成功的則成為follower，并且通過watch機(jī)制監(jiān)控著leader所創(chuàng)建的臨時節(jié)點(diǎn)，Zookeeper通過內(nèi)部心跳機(jī)制來確定leader的狀態(tài)，一旦leader出現(xiàn)意外Zookeeper能很快獲悉并且通知其他的follower，其他flower在之后作出相關(guān)反應(yīng)，這樣就完成了一個切換，這種模式也是比較通用的模式，基本大部分都是這樣實(shí)現(xiàn)的。但是這里面有個很嚴(yán)重的問題，如果注意不到會導(dǎo)致短暫的時間內(nèi)系統(tǒng)出現(xiàn)腦裂，因?yàn)樾奶霈F(xiàn)超時可能是leader掛了，但是也可能是zookeeper節(jié)點(diǎn)之間網(wǎng)絡(luò)出現(xiàn)了問題，導(dǎo)致leader假死的情況，leader其實(shí)并未死掉，但是與ZooKeeper之間的網(wǎng)絡(luò)出現(xiàn)問題導(dǎo)致Zookeeper認(rèn)為其掛掉了然后通知其他節(jié)點(diǎn)進(jìn)行切換，這樣follower中就有一個成為了leader，但是原本的leader并未死掉，這時候client也獲得leader切換的消息，但是仍然會有一些延時，zookeeper需要通訊需要一個一個通知，這時候整個系統(tǒng)就很混亂可能有一部分client已經(jīng)通知到了連接到新的leader上去了，有的client仍然連接在老的leader上，如果同時有兩個client需要對leader的同一個數(shù)據(jù)更新，并且剛好這兩個client此刻分別連接在新老的leader上，就會出現(xiàn)很嚴(yán)重問題。

總結(jié)： 假死：由于心跳超時（網(wǎng)絡(luò)原因?qū)е碌模┱J(rèn)為leader死了，但其實(shí)leader還存活著。 腦裂：由于假死會發(fā)起新的leader選舉，選舉出一個新的leader，但舊的leader網(wǎng)絡(luò)又通了，導(dǎo)致出現(xiàn)了兩個leader ，有的客戶端連接到老的leader，而有的客戶端則連接到新的leader。

17、Zookeeper腦裂是什么原因?qū)е碌模?/h2>

主要原因是Zookeeper集群和Zookeeper client判斷超時并不能做到完全同步，也就是說可能一前一后，如果是集群先于client發(fā)現(xiàn)，那就會出現(xiàn)上面的情況。同時，在發(fā)現(xiàn)并切換后通知各個客戶端也有先后快慢。一般出現(xiàn)這種情況的幾率很小，需要leader節(jié)點(diǎn)與Zookeeper集群網(wǎng)絡(luò)斷開，但是與其他集群角色之間的網(wǎng)絡(luò)沒有問題，還要滿足上面那些情況，但是一旦出現(xiàn)就會引起很嚴(yán)重的后果，數(shù)據(jù)不一致。

18、Zookeeper 是如何解決腦裂問題的？

要解決Split-Brain腦裂的問題，一般有下面幾種種方法：

Quorums (法定人數(shù)) 方式: 比如3個節(jié)點(diǎn)的集群，Quorums = 2, 也就是說集群可以容忍1個節(jié)點(diǎn)失效，這時候還能選舉出1個lead，集群還可用。比如4個節(jié)點(diǎn)的集群，它的Quorums = 3，Quorums要超過3，相當(dāng)于集群的容忍度還是1，如果2個節(jié)點(diǎn)失效，那么整個集群還是無效的。這是zookeeper防止"腦裂"默認(rèn)采用的方法。
Redundant communications (冗余通信)方式：集群中采用多種通信方式，防止一種通信方式失效導(dǎo)致集群中的節(jié)點(diǎn)無法通信。

Fencing (共享資源) 方式：比如能看到共享資源就表示在集群中，能夠獲得共享資源的鎖的就是Leader，看不到共享資源的，就不在集群中。要想避免zookeeper"腦裂"情況其實(shí)也很簡單，follower節(jié)點(diǎn)切換的時候不在檢查到老的leader節(jié)點(diǎn)出現(xiàn)問題后馬上切換，而是在休眠一段足夠的時間，確保老的leader已經(jīng)獲知變更并且做了相關(guān)的shutdown清理工作了然后再注冊成為master就能避免這類問題了，這個休眠時間一般定義為與zookeeper定義的超時時間就夠了，但是這段時間內(nèi)系統(tǒng)可能是不可用的，但是相對于數(shù)據(jù)不一致的后果來說還是值得的。
1、zooKeeper默認(rèn)采用了Quorums這種方式來防止"腦裂"現(xiàn)象。即只有集群中超過半數(shù)節(jié)點(diǎn)投票才能選舉出Leader。這樣的方式可以確保leader的唯一性,要么選出唯一的一個leader,要么選舉失敗。在zookeeper中Quorums作用如下：*集群中最少的節(jié)點(diǎn)數(shù)用來選舉leader保證集群可用。通知客戶端數(shù)據(jù)已經(jīng)安全保存前集群中最少數(shù)量的節(jié)點(diǎn)數(shù)已經(jīng)保存了該數(shù)據(jù)。*一旦這些節(jié)點(diǎn)保存了該數(shù)據(jù)，客戶端將被通知已經(jīng)安全保存了，可以繼續(xù)其他任務(wù)。而集群中剩余的節(jié)點(diǎn)將會最終也保存了該數(shù)據(jù)。

假設(shè)某個leader假死，其余的followers選舉出了一個新的leader。這時，舊的leader復(fù)活并且仍然認(rèn)為自己是leader，這個時候它向其他followers發(fā)出寫請求也是會被拒絕的。因?yàn)槊慨?dāng)新leader產(chǎn)生時，會生成一個epoch標(biāo)號(標(biāo)識當(dāng)前屬于那個leader的統(tǒng)治時期)，這個epoch是遞增的，followers如果確認(rèn)了新的leader存在，知道其epoch，就會拒絕epoch小于現(xiàn)任leader epoch的所有請求。那有沒有follower不知道新的leader存在呢，有可能，但肯定不是大多數(shù)，否則新leader無法產(chǎn)生。Zookeeper的寫也遵循quorum機(jī)制，因此，得不到大多數(shù)支持的寫是無效的，舊leader即使各種認(rèn)為自己是leader，依然沒有什么作用。zookeeper除了可以采用上面默認(rèn)的Quorums方式來避免出現(xiàn)"腦裂"，還可以可采用下面的預(yù)防措施：

2、添加冗余的心跳線，例如雙線條線，盡量減少“裂腦”發(fā)生機(jī)會。

3、啟用磁盤鎖。正在服務(wù)一方鎖住共享磁盤，"裂腦"發(fā)生時，讓對方完全"搶不走"共享磁盤資源。但使用鎖磁盤也會有一個不小的問題，如果占用共享盤的一方不主動"解鎖"，另一方就永遠(yuǎn)得不到共享磁盤?，F(xiàn)實(shí)中假如服務(wù)節(jié)點(diǎn)突然死機(jī)或崩潰，就不可能執(zhí)行解鎖命令。后備節(jié)點(diǎn)也就接管不了共享資源和應(yīng)用服務(wù)。于是有人在HA中設(shè)計(jì)了"智能"鎖。即正在服務(wù)的一方只在發(fā)現(xiàn)心跳線全部斷開（察覺不到對端）時才啟用磁盤鎖。平時就不上鎖了。

?4、設(shè)置仲裁機(jī)制。例如設(shè)置參考IP（如網(wǎng)關(guān)IP），當(dāng)心跳線完全斷開時，2個節(jié)點(diǎn)都各自ping一下 參考IP，不通則表明斷點(diǎn)就出在本端，不僅"心跳"、還兼對外"服務(wù)"的本端網(wǎng)絡(luò)鏈路斷了，即使啟動（或繼續(xù)）應(yīng)用服務(wù)也沒有用了，那就主動放棄競爭，讓能夠ping通參考IP的一端去起服務(wù)。更保險(xiǎn)一些，ping不通參考IP的一方干脆就自我重啟，以徹底釋放有可能還占用著的那些共享資源。

19、Zookeeper選舉中投票信息的五元組是什么？

Leader：被選舉的 Leader 的 SID

Zxid：被選舉的 Leader 的事務(wù) ID

Sid：當(dāng)前服務(wù)器的 SID

electionEpoch：當(dāng)前投票的輪次

peerEpoch：當(dāng)前服務(wù)器的 Epoch

Epoch > Zxid > Sid

Epoch，Zxid 都可能一致，但是 Sid 一定不一樣，這樣兩張選票一定會 PK 出結(jié)果。

20、講解一下 ZooKeeper 的持久化機(jī)制

什么是持久化？

數(shù)據(jù)，存到磁盤或者文件當(dāng)中。機(jī)器重啟后，數(shù)據(jù)不會丟失。內(nèi)存 -> 磁盤的映射，和序列化有些像。

ZooKeeper 的持久化

SnapShot 快照，記錄內(nèi)存中的全量數(shù)據(jù)，TxnLog 增量事務(wù)日志，記錄每一條增刪改記錄（查不是事務(wù)日志，不會引起數(shù)據(jù)變化）

為什么持久化這么麻煩，一個不可用嗎？

快照的缺點(diǎn)，文件太大，而且快照文件不會是最新的數(shù)據(jù)。 增量事務(wù)日志的缺點(diǎn)，運(yùn)行時間了，日志太多了，加載太慢。二者結(jié)合最好?？煺漳Ｊ剑簩?ZooKeeper 內(nèi)存中以 DataTree 數(shù)據(jù)結(jié)構(gòu)存儲的數(shù)據(jù)定期存儲到磁盤中。由于快照文件是定期對數(shù)據(jù)的全量備份，所以快照文件中數(shù)據(jù)通常不是最新的。見圖片：

21、在Zookeeper中Zxid和Epoch是什么，有什么作用？

Zxid：也就是事務(wù) id，為了保證事務(wù)的順序一致性，ZooKeeper 采用了遞增的事務(wù) Zxid 來標(biāo)識事務(wù)。proposal 都會加上了 Zxid。Zxid 是一個 64 位的數(shù)字，它高 32 位是 Epoch 用來標(biāo)識朝代變化，比如每次選舉 Epoch 都會加改變。低 32 位用于遞增計(jì)數(shù)。
Epoch：可以理解為當(dāng)前集群所處的年代或者周期，每個 Leader 就像皇帝，都有自己的年號，所以每次改朝換代，Leader 變更之后，都會在前一個年代的基礎(chǔ)上加 1。這樣就算舊的 Leader 崩潰恢復(fù)之后，也沒有人聽它的了，因?yàn)?Follower 只聽從當(dāng)前年代的 Leader 的命令。

22、ZooKeeper 負(fù)載均衡和 Nginx 負(fù)載均衡有什么區(qū)別？

ZooKeeper：

• 不存在單點(diǎn)問題，zab 機(jī)制保證單點(diǎn)故障可重新選舉一個 Leader

• 只負(fù)責(zé)服務(wù)的注冊與發(fā)現(xiàn)，不負(fù)責(zé)轉(zhuǎn)發(fā)，減少一次數(shù)據(jù)交換（消費(fèi)方與服務(wù)方直接通信）

• 需要自己實(shí)現(xiàn)相應(yīng)的負(fù)載均衡算法

Nginx：

• 存在單點(diǎn)問題，單點(diǎn)負(fù)載高數(shù)據(jù)量大，需要通過 KeepAlived 輔助實(shí)現(xiàn)高可用

• 每次負(fù)載，都充當(dāng)一次中間人轉(zhuǎn)發(fā)角色，本身是個反向代理服務(wù)器

• 自帶負(fù)載均衡算法

23、說說ZooKeeper 的序列化

序列化：

• 內(nèi)存數(shù)據(jù)，保存到硬盤需要序列化。

• 內(nèi)存數(shù)據(jù)，通過網(wǎng)絡(luò)傳輸?shù)狡渌?jié)點(diǎn)，需要序列化。

ZK 使用的序列化協(xié)議是 Jute，Jute 提供了 Record 接口。接口提供了兩個方法：

• serialize 序列化方法

• deserialize 反序列化方法

如果要序列化，在這兩個方法中存入到流對象中即可。

24、說說Zookeeper中的ACL 權(quán)限控制機(jī)制

UGO（User/Group/Others）目前在 Linux/Unix 文件系統(tǒng)中使用，也是使用最廣泛的權(quán)限控制方式。是一種粗粒度的文件系統(tǒng)權(quán)限控制模式。

ACL（Access Control List）訪問控制列表包括三個方面：
權(quán)限模式（Scheme）

（1）IP：從 IP 地址粒度進(jìn)行權(quán)限控制

（2）Digest：最常用，用類似于 username:password 的權(quán)限標(biāo)識來進(jìn)行權(quán)限配置，便于區(qū)分不同應(yīng)用來進(jìn)行權(quán)限控制

（3）World：最開放的權(quán)限控制方式，是一種特殊的 digest 模式，只有一個權(quán)限標(biāo)識“world:anyone”

（4）Super：超級用戶

授權(quán)對象

授權(quán)對象指的是權(quán)限賦予的用戶或一個指定實(shí)體，例如 IP 地址或是機(jī)器燈。

權(quán)限 Permission

（1）CREATE：數(shù)據(jù)節(jié)點(diǎn)創(chuàng)建權(quán)限，允許授權(quán)對象在該 Znode 下創(chuàng)建子節(jié)點(diǎn)

（2）DELETE：子節(jié)點(diǎn)刪除權(quán)限，允許授權(quán)對象刪除該數(shù)據(jù)節(jié)點(diǎn)的子節(jié)點(diǎn)

（3）READ：數(shù)據(jù)節(jié)點(diǎn)的讀取權(quán)限，允許授權(quán)對象訪問該數(shù)據(jù)節(jié)點(diǎn)并讀取其數(shù)據(jù)內(nèi)容或子節(jié)點(diǎn)列表等

（4）WRITE：數(shù)據(jù)節(jié)點(diǎn)更新權(quán)限，允許授權(quán)對象對該數(shù)據(jù)節(jié)點(diǎn)進(jìn)行更新操作

（5）ADMIN：數(shù)據(jù)節(jié)點(diǎn)管理權(quán)限，允許授權(quán)對象對該數(shù)據(jù)節(jié)點(diǎn)進(jìn)行 ACL 相關(guān)設(shè)置操作

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

Zookeeper 有三種部署模式：

1. 單機(jī)部署：一臺集群上運(yùn)行；

2. 集群部署：多臺集群運(yùn)行；

3. 偽集群部署：一臺集群啟動多個 Zookeeper 實(shí)例運(yùn)行。

26、描述一下 ZAB 協(xié)議

ZAB 協(xié)議是 ZooKeeper 自己定義的協(xié)議，全名 ZooKeeper 原子廣播協(xié)議。

ZAB 協(xié)議有兩種模式：Leader 節(jié)點(diǎn)崩潰了如何恢復(fù)和消息如何廣播到所有節(jié)點(diǎn)。

整個 ZooKeeper 集群沒有 Leader 節(jié)點(diǎn)的時候，屬于崩潰的情況。比如集群啟動剛剛啟動，這時節(jié)點(diǎn)們互相不認(rèn)識。比如運(yùn)作 Leader 節(jié)點(diǎn)宕機(jī)了，又或者網(wǎng)絡(luò)問題，其他節(jié)點(diǎn) Ping 不通 Leader 節(jié)了。這時就需要 ZAB 中的節(jié)點(diǎn)崩潰協(xié)議，所有節(jié)點(diǎn)進(jìn)入選舉模式，選舉出新的 Leader。整個選舉過程就是通過廣播來實(shí)現(xiàn)的。選舉成功后，一切都需要以 Leader 的數(shù)據(jù)為準(zhǔn)，那么就需要進(jìn)行數(shù)據(jù)同步了。

27、ZAB 和 Paxos 算法的聯(lián)系與區(qū)別？

相同點(diǎn)：

（1）兩者都存在一個類似于 Leader 進(jìn)程的角色，由其負(fù)責(zé)協(xié)調(diào)多個 Follower 進(jìn)程的運(yùn)行
（2）Leader 進(jìn)程都會等待超過半數(shù)的 Follower 做出正確的反饋后，才會將一個提案進(jìn)行提交
（3）ZAB 協(xié)議中，每個 Proposal 中都包含一個 epoch 值來代表當(dāng)前的 Leader周期，Paxos 中名字為 Ballot
不同點(diǎn)：
??? ZAB 用來構(gòu)建高可用的分布式數(shù)據(jù)主備系統(tǒng)（Zookeeper），Paxos 是用來構(gòu)建分布式一致性狀態(tài)機(jī)系統(tǒng)。

28、Zookeeper集群支持動態(tài)添加機(jī)器嗎？

其實(shí)就是水平擴(kuò)容了，Zookeeper 在這方面不太好。兩種方式：

全部重啟：關(guān)閉所有 Zookeeper 服務(wù)，修改配置之后啟動。不影響之前客戶端的會話。

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

用的方式。

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

詳細(xì)學(xué)習(xí)Zookeeper入門和進(jìn)階知識，請閱讀：

入門：zookeeper快速入門

進(jìn)階：zookeeper進(jìn)階（watcher機(jī)制、數(shù)據(jù)同步流程、分布式鎖）

JAVA面試寶典，搞定JAVA面試，不再是難題，系列文章傳送地址，請點(diǎn)擊本鏈接。https://blog.csdn.net/wanghaiping1993/article/details/125075785文章來源地址http://www.zghlxwxcb.cn/news/detail-809871.html

到了這里，關(guān)于28道Zookeeper面試題及答案的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！