面試的時候，面試官只要看到你簡歷的上寫的有Zookeeper(熟悉、掌握)之類，那你至少要準(zhǔn)備接下來的11連問。 

NO1：說說zookeeper是什么?

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

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

NO2：了解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)。

NO3：能說說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與之同步。

NO4：Zookeeper為什么要這么設(shè)計(jì)?

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

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

• 采用樹形結(jié)構(gòu)組織數(shù)據(jù)節(jié)點(diǎn);
• 全量數(shù)據(jù)節(jié)點(diǎn)，都存儲在內(nèi)存中;
• Follower 和 Observer 直接處理非事務(wù)請求;

高可用(構(gòu)建集群)

• 半數(shù)以上機(jī)器存活，服務(wù)就能正常運(yùn)行
• 自動進(jìn)行 Leader 選舉

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

• 每個事務(wù)請求，都會轉(zhuǎn)發(fā)給 Leader 處理
• 每個事務(wù)，會分配全局唯一的遞增id(zxid，64位：epoch + 自增 id)

最終一致性

• 通過提議投票方式，保證事務(wù)提交的可靠性
• 提議投票方式，只能保證 Client 收到事務(wù)提交成功后，半數(shù)以上節(jié)點(diǎn)能夠看到最新數(shù)據(jù)

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

系統(tǒng)模型：

領(lǐng)導(dǎo)者(leader)

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

學(xué)習(xí)者(learner)

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

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

NO6：你熟悉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有四種形式：

• 持久化目錄節(jié)點(diǎn)(PERSISTENT)：客戶端與Zookeeper斷開連接后，該節(jié)點(diǎn)依舊存在持久化順序編號目錄節(jié)點(diǎn)(PERSISTENT_SEQUENTIAL)
• 客戶端與Zookeeper斷開連接后，該節(jié)點(diǎn)依舊存在，只是Zookeeper給該節(jié)點(diǎn)名稱進(jìn)行順序編號：臨時目錄節(jié)點(diǎn)(EPHEMERAL)
• 客戶端與Zookeeper斷開連接后，該節(jié)點(diǎn)被刪除：臨時順序編號目錄節(jié)點(diǎn)(EPHEMERAL_SEQUENTIAL)
• 客戶端與Zookeeper斷開連接后，該節(jié)點(diǎn)被刪除，只是Zookeeper給該節(jié)點(diǎn)名稱進(jìn)行順序編號

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

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

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

[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的核心是原子廣播，這個機(jī)制保證了各個Server之間的同步。實(shí)現(xiàn)這個機(jī)制的協(xié)議叫做Zab協(xié)議。Zab協(xié)議有兩種模式，它們分別是恢復(fù)模式(選主)和廣播模式(同步)。當(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)。leader選舉是保證分布式數(shù)據(jù)一致性的關(guān)鍵。

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

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

• 服務(wù)器初始化啟動。
• 服務(wù)器運(yùn)行期間無法和leader保持連接。

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

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

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

重點(diǎn)是leader不可用了，此時的選主制度。

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

• sid：即server id，用來標(biāo)識該機(jī)器在集群中的機(jī)器序號。
• zxid：即zookeeper事務(wù)id號。

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

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

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

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

規(guī)則如下：

• 初始階段，都會給自己投票。
• 當(dāng)接收到來自其他服務(wù)器的投票時，都需要將別人的投票和自己的投票進(jìn)行pk，規(guī)則如下：

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

NO8：有了解過watch機(jī)制嗎?

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

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

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

什么是watcher?

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

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

• 服務(wù)注冊：服務(wù)提供者(Provider)啟動時，會向zookeeper服務(wù)端注冊服務(wù)信息，也就是創(chuàng)建一個節(jié)點(diǎn)，例如：用戶注冊服務(wù)com.xxx.user.register，并在節(jié)點(diǎn)上存儲服務(wù)的相關(guān)數(shù)據(jù)(如服務(wù)提供者的ip地址、端口等)。
• 服務(wù)發(fā)現(xiàn)：服務(wù)消費(fèi)者(Consumer)啟動時，根據(jù)自身配置的依賴服務(wù)信息，向zookeeper服務(wù)端獲取注冊的服務(wù)信息并設(shè)置watch監(jiān)聽，獲取到注冊的服務(wù)信息之后，將服務(wù)提供者的信息緩存在本地，并進(jìn)行服務(wù)的調(diào)用。
• 服務(wù)通知：一旦服務(wù)提供者因某種原因宕機(jī)不再提供服務(wù)之后，客戶端與zookeeper服務(wù)端斷開連接，zookeeper服務(wù)端上服務(wù)提供者對應(yīng)服務(wù)節(jié)點(diǎn)會被刪除(例如：用戶注冊服務(wù)com.xxx.user.register)，隨后zookeeper服務(wù)端會異步向所有消費(fèi)用戶注冊服務(wù)com.xxx.user.register，且設(shè)置了watch監(jiān)聽的服務(wù)消費(fèi)者發(fā)出節(jié)點(diǎn)被刪除的通知，消費(fèi)者根據(jù)收到的通知拉取最新服務(wù)列表，更新本地緩存的服務(wù)列表。

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

watcher有哪些類型?

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

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

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

watcher有什么特性?

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

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

NO9：那你說說Zookeeper有哪些應(yīng)用場景?

數(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):
• 數(shù)據(jù)量小的KV
• 數(shù)據(jù)內(nèi)容在運(yùn)行時會發(fā)生動態(tài)變化
• 集群機(jī)器共享，配置一致

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

• 推: 服務(wù)端會推給注冊了監(jiān)控節(jié)點(diǎn)的客戶端 Wathcer 事件通知
• 答: 客戶端獲得通知后，然后主動到服務(wù)端拉取最新的數(shù)據(jù)

命名服務(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ù)列表類。

配置管理

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

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

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

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

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

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

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

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

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

集群管理

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

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

• 希望知道集群中究竟有多少機(jī)器在工作
• 對集群中的每臺機(jī)器的運(yùn)行時狀態(tài)進(jìn)行數(shù)據(jù)收集
• 對集群中機(jī)器進(jìn)行上下線的操作

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

• 分布式環(huán)境中，實(shí)時掌握每個節(jié)點(diǎn)的狀態(tài)是必要的，可根據(jù)節(jié)點(diǎn)實(shí)時狀態(tài)做出一些調(diào)整。
• 可交由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)建成功

分布式通知與協(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)。

分布式鎖

處于不同節(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ù)編號的大小控制鎖。

分布式隊(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)者模型。

NO10：知道監(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()方法。

NO11：為什么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ù)相同的情況。

總結(jié)

很多面試官，面試套路基本就是這個，從背景到原理，到架構(gòu)體系，再到Zookeeper固有特點(diǎn)、最后要求面試者能說出Zookeeper的實(shí)際應(yīng)用場景。