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

ZooKe叩er是什么？

?ZooKeeper是一個開源的分布式協(xié)調(diào)服務(wù)。它是一個為分布式應(yīng)用提供一致性服務(wù)的軟件，分布

式應(yīng)用程序可以基于Zookeeper實現(xiàn)諸如數(shù)據(jù)發(fā)布/訂閱、負載均衡、命名服務(wù)、分布式協(xié)調(diào)/通

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

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

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

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

(1)順序一致性

(2)原子性

(3)單一視圖

(4)可靠性

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

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

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

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

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

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

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

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

ZooKe叩er提供了什么？

?文件系統(tǒng)

?通知機制

Zookeeper文件系統(tǒng)

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

點都可以設(shè)置關(guān)聯(lián)的數(shù)據(jù)，而文件系統(tǒng)中只有文件節(jié)點可以存放數(shù)據(jù)而目錄節(jié)點不行。

?Zookeeper為了保證高吞吐和低延遲，在內(nèi)存中維護了這個樹狀的目錄結(jié)構(gòu)，這種特性使得

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

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

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

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

恢復(fù)模式

?當(dāng)服務(wù)啟動或者在領(lǐng)導(dǎo)者崩潰后，Zab就進入了恢復(fù)模式，當(dāng)領(lǐng)導(dǎo)者被選舉出來，且大多數(shù)server

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

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

廣播模式

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

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

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

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

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

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

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

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

除。

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

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

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

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

ZookeeperWatcher機制-數(shù)據(jù)變更通知

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

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

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

?工作機制：

(1)客戶端注冊watcher

(2)服務(wù)端處理watcher

(3)客戶端回調(diào)watcher

Watcher特性總結(jié)

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

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

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

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

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

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

務(wù)端，僅僅是在客戶端請求中使用boolean類型屬性進行了標(biāo)記。

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

題，不同的客戶端和服務(wù)器之間通過socket進行通信，由于網(wǎng)絡(luò)延遲或其他因素導(dǎo)致客戶端在不

通的時刻監(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.當(dāng)一個客戶端連接到一個新的服務(wù)器上時，watch將會被以任意會話事件觸發(fā)。當(dāng)與一個服務(wù)器

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

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

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

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

客戶端注冊Watcher實現(xiàn)

?(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中進行管理

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

服務(wù)端處理Watcher實現(xiàn)

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

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

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

WatchTable和watch2Paths中去。

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

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

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

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

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

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

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

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

Watcher事件通知。

客戶端回調(diào)Watcher

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

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

ACL權(quán)限控制機制

?UGO(User/Group/Others)

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

權(quán)限控制模式.

?ACL(AccessControlList)訪問控制列表

?包括三個方面：

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

username:password的權(quán)限標(biāo)識來進行權(quán)限配置，便于區(qū)分不同應(yīng)用來進行權(quán)限控制(3)

World:最開放的權(quán)限控制方式，是一種特殊的digest模式，只有一個權(quán)限標(biāo)識"worldanyone"

(4)Super:超級用戶

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

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

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

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

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

許授權(quán)對象對該數(shù)據(jù)節(jié)點進行ACL相關(guān)設(shè)置操作

Chroot特性

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

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

下。

?通過設(shè)置Chroot,能夠?qū)⒁粋€客戶端應(yīng)用于Zookeeper服務(wù)端的一顆子樹相對應(yīng)，在那些多個應(yīng)

用公用一個Zookeeper進群的場景下，對實現(xiàn)不同應(yīng)用間的相互隔離非常有幫助。

會話管理

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

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

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

?計算公式：

ExpirationTime_=currentTime+sessionTimeout

ExpirationTime=(ExpirationTime_/Expirationlnrerval+1)*

Expirationinterval,Expirationinterval是指Zookeeper會話超時檢查時間間隔，默認(rèn)tickTime

服務(wù)器角色

?Leader

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

(2)集群內(nèi)部各服務(wù)的調(diào)度者

?Follower

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

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

(3)參與Leader選舉投票

?Observer

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

務(wù)處理能力

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

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

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

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

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

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

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

(3)LEADING:領(lǐng)導(dǎo)者狀態(tài)。表明當(dāng)前服務(wù)器角色是Leader。

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

數(shù)據(jù)同步

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

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

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

oLearner向Learder注冊

。數(shù)據(jù)同步

。同步確認(rèn)

?Zookeeper的數(shù)據(jù)同步通常分為四類：

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

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

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

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

?在進行數(shù)據(jù)同步前，Leader服務(wù)器會完成數(shù)據(jù)同步初始化：

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

服務(wù)器最后處理的ZXID)

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

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

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

之間

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

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

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

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

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

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

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

zookeeper是如何保證事務(wù)的順序一致性的？

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

zxid,zxid實際上是一個64位的數(shù)字，高32位是epoch（時期;紀(jì)元;世;新時代）用來標(biāo)識

leader周期，如果有新的leader產(chǎn)生出來，epoch會自增，低32位用來遞增計數(shù)。當(dāng)新產(chǎn)生

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

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

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

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

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

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

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

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

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

的，數(shù)據(jù)并不會丟失；

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

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

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

所以

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

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

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

?Zk的負載均衡是可以調(diào)控，nginx只是能調(diào)權(quán)重，其他需要可控的都需要自己寫插件；但是nginx

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

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

?Zookeeper有三種部署模式：

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

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

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

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

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

使用嗎？

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

可以繼續(xù)使用.

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

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

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

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

用的方式。

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

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

么不是永久的？

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

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

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

通知到所有的客戶端，給網(wǎng)絡(luò)和服務(wù)器造成很大壓力。

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

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

?，八、丫

U而發(fā)送。

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

可。

Zookeeper的java客戶端都有哪些？

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

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

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

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

說幾個zookeeper常用的命令。

?常用命令：Isgetsetcreatedelete等。

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

?相同點：

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

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

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

名字為Ballot

?不同點：

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

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

Zookeeper的典型應(yīng)用場景

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

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

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

的構(gòu)建一系列分布式應(yīng)用中年都會涉及的核心功能，如：

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

(2)負載均衡

(3)命名服務(wù)

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

(5)集群管理

(6)Master選舉

(7)分布式鎖

(8)分布式隊列

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

介紹

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

目的

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

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

設(shè)計模式

?Push模式

?Pull模式

數(shù)據(jù)(配置信息)特性

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

?如：機器列表信息、運行時開關(guān)配置、數(shù)據(jù)庫配置信息等

基于Zookeeper的實現(xiàn)方式

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

??數(shù)據(jù)獲?。簯?yīng)用在啟動初始化節(jié)點從Zookeeper數(shù)據(jù)節(jié)點讀取數(shù)據(jù)，并在該節(jié)點上注冊一個數(shù)

據(jù)變更Watcher

??數(shù)據(jù)變更：當(dāng)變更數(shù)據(jù)時，更新Zookeeper對應(yīng)節(jié)點數(shù)據(jù)，Zookeeper會將數(shù)據(jù)變更通知發(fā)到

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

2負載均衡

?zk的命名服務(wù)

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

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

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

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

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

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

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

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

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

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

的對象等等。

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

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

時，也就是znode發(fā)生變化時，可以通過改變zk中某個目錄節(jié)點的內(nèi)容，利用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)，鎖的問題變得容易。鎖服務(wù)可以分為兩類，f是保持獨

占，另一個是控制時序。

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

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

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

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

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

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

?兩種類型的隊列：

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

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

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

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

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

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

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

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

Zookeeper都有哪些功能？

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

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

的過程，使用Zoo