一文徹底搞懂 zookeeper 核心知識點

1. ZooKeeper 是什么？

1. ZooKeeper 是什么？

ZooKeeper 是一個開源的分布式協(xié)調(diào)服務(wù)。它是一個為分布式應(yīng)用提供一致性服務(wù)的軟件，分布式應(yīng)用程序可以基于 Zookeeper 實現(xiàn)諸如數(shù)據(jù)發(fā)布/訂閱、負載均衡、命名服務(wù)、分布式協(xié)調(diào)/通知、集群管理、Master 選舉、分布式鎖和分布式隊列等功能。

ZooKeeper 的目標就是封裝好復(fù)雜易出錯的關(guān)鍵服務(wù)，將簡單易用的接口和性能高效、功能穩(wěn)定的系統(tǒng)提供給用戶。

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

（1）順序一致性

（2）原子性

（3）單一視圖

（4）可靠性

（5）實時性（最終一致性）

客戶端的讀請求可以被集群中的任意一臺機器處理，如果讀請求在節(jié)點上注冊了-，這個-也是由所連接的 zookeeper 機器來處理。對于寫請求，這些請求會同時發(fā)給其他 zookeeper 機器并且達成一致后，請求才會返回成功。因此，隨著 zookeeper 的集群機器增多，讀請求的吞吐會提高但是寫請求的吞吐會下降。

有序性是 zookeeper 中非常重要的一個特性，所有的更新都是全局有序的，每個更新都有一個唯一的時間戳，這個時間戳稱為 zxid（Zookeeper Transaction Id）。而讀請求只會相對于更新有序，也就是讀請求的返回結(jié)果中會帶有這個zookeeper 最新的 zxid。

2. ZooKeeper 提供了什么？

文件系統(tǒng)

通知機制

3. 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ù)上限為1M。

4. 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 支持。

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

（1）PERSISTENT-持久節(jié)點

除非手動刪除，否則節(jié)點一直存在于 Zookeeper 上

（2）EPHEMERAL-臨時節(jié)點

臨時節(jié)點的生命周期與客戶端會話綁定，一旦客戶端會話失效（客戶端與zookeeper 連接斷開不一定會話失效），那么這個客戶端創(chuàng)建的所有臨時節(jié)點都會被移除。

（3）PERSISTENT_SEQUENTIAL-持久順序節(jié)點

基本特性同持久節(jié)點，只是增加了順序?qū)傩裕?jié)點名后邊會追加一個由父節(jié)點維護的自增整型數(shù)字。

（4）EPHEMERAL_SEQUENTIAL-臨時順序節(jié)點

基本特性同臨時節(jié)點，增加了順序?qū)傩裕?jié)點名后邊會追加一個由父節(jié)點維護的自增整型數(shù)字。

6. Zookeeper Watcher 機制 – 數(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 類型屬性進行了標記。

（4）watcher event 異步發(fā)送 watcher 的通知事件從 server 發(fā)送到 client 是異步的，這就存在一個問題，不同的客戶端和服務(wù)器之間通過 socket 進行通信，由于網(wǎng)絡(luò)延遲或其他因素導(dǎo)致客戶端在不通的時刻監(jiān)聽到事件，由于 Zookeeper 本身提供了 ordering guarantee，即客戶端監(jiān)聽事件后，才會感知它所監(jiān)視 znode發(fā)生了變化。所以我們使用 Zookeeper 不能期望能夠監(jiān)控到節(jié)點每次的變化。Zookeeper 只能保證最終的一致性，而無法保證強一致性。

（5）注冊 watcher getData、exists、getChildren

（6）觸發(fā) watcher create、delete、setData

（7）當(dāng)一個客戶端連接到一個新的服務(wù)器上時，watch 將會被以任意會話事件觸發(fā)。當(dāng)與一個服務(wù)器失去連接的時候，是無法接收到 watch 的。而當(dāng) client 重新連接時，如果需要的話，所有先前注冊過的 watch，都會被重新注冊。通常這是完全透明的。只有在一個特殊情況下，watch 可能會丟失：對于一個未創(chuàng)建的 znode的 exist watch，如果在客戶端斷開連接期間被創(chuàng)建了，并且隨后在客戶端連接上之前又刪除了，這種情況下，這個 watch 事件可能會被丟失。

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

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

（2）標記請求 request，封裝 Watcher 到 WatchRegistration

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

（4）收到服務(wù)端響應(yīng)后，將 Watcher 注冊到 ZKWatcherManager 中進行管理

（5）請求返回，完成注冊。

8. 服務(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 找到；提取并從 WatchTable 和 Watch2Paths 中刪除對應(yīng) Watcher（從這里可以看出 Watcher 在服務(wù)端是一次性的，觸發(fā)一次就失效了）

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

這里 process 主要就是通過 ServerCnxn 對應(yīng)的 TCP 連接發(fā)送 Watcher 事件通知。

9. 客戶端回調(diào) Watcher

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

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

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

UGO（User/Group/Others）

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

ACL（Access Control List）訪問控制列表

包括三個方面：

權(quán)限模式（Scheme）

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

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

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

（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è)置操作

11. 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)用間的相互隔離非常有幫助。

12. 會話管理

分桶策略：將類似的會話放在同一區(qū)塊中進行管理，以便于 Zookeeper 對會話進行不同區(qū)塊的隔離處理以及同一區(qū)塊的統(tǒng)一處理。

分配原則：每個會話的“下次超時時間點”（ExpirationTime）

計算公式：

ExpirationTime_ = currentTime + sessionTimeout

ExpirationTime = (ExpirationTime_ / ExpirationInrerval + 1) *

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

13. 服務(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）不參與任何形式的投票

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

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

（1）LOOKING：尋 找 Leader 狀態(tài)。當(dāng)服務(wù)器處于該狀態(tài)時，它會認為當(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。

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

整個集群完成 Leader 選舉之后，Learner（Follower 和 Observer 的統(tǒng)稱）會向Leader 服務(wù)器進行注冊。當(dāng) Learner 服務(wù)器xiang?Leader 服務(wù)器完成注冊后，進入數(shù)據(jù)同步環(huán)節(jié)。

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

Learner 向 Learder 注冊

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

同步確認

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

（1）直接差異化同步（DIFF 同步）

（2）先回滾再差異化同步（TRUNC+DIFF 同步）

（3）僅回滾同步（TRUNC 同步）

（4）全量同步（SNAP 同步）

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

peerLastZxid：

· 從 learner 服務(wù)器注冊時發(fā)送的 ACKEPOCH 消息中提取 lastZxid（該Learner 服務(wù)器最后處理的 ZXID）

minCommittedLog：

· Leader 服務(wù)器 Proposal 緩存隊列 committedLog 中最小 ZXIDmaxCommittedLog：

· Leader 服務(wù)器 Proposal 緩存隊列 committedLog 中最大 ZXID直接差異化同步（DIFF 同步）

· 場景：peerLastZxid 介于 minCommittedLog 和 maxCommittedLog之間先回滾再差異化同步（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

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

zookeeper 采用了全局遞增的事務(wù) Id 來標識，所有的 proposal（提議）都在被提出的時候加上了 zxid，zxid 實際上是一個 64 位的數(shù)字，高 32 位是 epoch（ 時期; 紀元; 世; 新時代）用來標識 leader 周期，如果有新的 leader 產(chǎn)生出來，epoch會自增，低 32 位用來遞增計數(shù)。當(dāng)新產(chǎn)生 proposal 的時候，會依據(jù)數(shù)據(jù)庫的兩階段過程，首先會向其他的 server 發(fā)出事務(wù)執(zhí)行請求，如果超過半數(shù)的機器都能執(zhí)行并且能夠成功，那么就會開始執(zhí)行。

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

在分布式環(huán)境中，有些業(yè)務(wù)邏輯只需要集群中的某一臺機器進行執(zhí)行，其他的機器可以共享這個結(jié)果，這樣可以大大減少重復(fù)計算，提高性能，于是就需要進行 leader 選舉。

18. 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)

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

zk 的負載均衡是可以調(diào)控，nginx 只是能調(diào)權(quán)重，其他需要可控的都需要自己寫插件；但是 nginx 的吞吐量比 zk 大很多，應(yīng)該說按業(yè)務(wù)選擇用哪種方式。

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

Zookeeper 有三種部署模式：

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

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

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

21. 集群最少要幾臺機器，集群規(guī)則是怎樣的？集群中有 3 臺服務(wù)器，其中一個節(jié)點宕機，這個時候 Zookeeper 還可以使用嗎？

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

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

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

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

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

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

23. 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í)行 getData(“/節(jié)點 A”,true)，如果節(jié)點 A 發(fā)生了變更或刪除，客戶端會得到它的 watch 事件，但是在之后節(jié)點 A 又發(fā)生了變更，而客戶端又沒有設(shè)置 watch 事件，就不再給客戶端發(fā)送。

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

24. Zookeeper 的 java 客戶端都有哪些？

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

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

chubby 是 google 的，完全實現(xiàn) paxos 算法，不開源。zookeeper 是 chubby的開源實現(xiàn)，使用 zab 協(xié)議，paxos 算法的變種。

26. 說幾個 zookeeper 常用的命令。

常用命令：ls get set create delete 等。

27. 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)。

28. 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）分布式隊列

數(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ù)即可。

負載均衡

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ù)可以分為兩類，一個是保持獨占，另一個是控制時序。

對于第一類，我們將 zookeeper 上的一個 znode 看作是一把鎖，通過 createznode的方式來實現(xiàn)。所有客戶端都去創(chuàng)建 /distribute_lock 節(jié)點，最終成功創(chuàng)建的那個客戶端也即擁有了這把鎖。用完刪除掉自己創(chuàng)建的 distribute_lock 節(jié)點就釋放出鎖。

對于第二類， /distribute_lock 已經(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)建成功時Watcher 通知等待的隊列，隊列刪除序列號最小的節(jié)點用以消費。此場景下Zookeeper 的 znode 用于消息存儲，znode 存儲的數(shù)據(jù)就是消息隊列中的消息內(nèi)容，SEQUENTIAL 序列號就是消息的編號，按序取出即可。由于創(chuàng)建的節(jié)點是持久化的，所以不必擔(dān)心隊列消息的丟失問題。

29. Zookeeper 都有哪些功能？

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

主節(jié)點選舉：主節(jié)點掛掉了之后可以從備用的節(jié)點開始新一輪選主，主節(jié)點選舉說的就是這個選舉的過程，使用 Zookeeper 可以協(xié)助完成這個過程；

分布式鎖：Zookeeper 提供兩種鎖：獨占鎖、共享鎖。獨占鎖即一次只能有一個線程使用資源，共享鎖是讀鎖共享，讀寫互斥，即可以有多線線程同時讀同一個資源，如果要使用寫鎖也只能有一個線程使用。Zookeeper 可以對分布式鎖進行控制。

命名服務(wù)：在分布式系統(tǒng)中，通過使用命名服務(wù)，客戶端應(yīng)用能夠根據(jù)指定名字來獲取資源或服務(wù)的地址，提供者等信息。

30. 說一下 Zookeeper 的通知機制？

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

31. Zookeeper 和 Dubbo 的關(guān)系？

Zookeeper的作用：

zookeeper用來注冊服務(wù)和進行負載均衡，哪一個服務(wù)由哪一個機器來提供必須讓調(diào)用者知道，簡單來說就是ip地址和服務(wù)名稱的對應(yīng)關(guān)系。當(dāng)然也可以通過硬編碼的方式把這種對應(yīng)關(guān)系在調(diào)用方業(yè)務(wù)代碼中實現(xiàn)，但是如果提供服務(wù)的機器掛掉調(diào)用者無法知曉，如果不更改代碼會繼續(xù)請求掛掉的機器提供服務(wù)。zookeeper通過心跳機制可以檢測掛掉的機器并將掛掉機器的ip和服務(wù)對應(yīng)關(guān)系從列表中刪除。至于支持高并發(fā)，簡單來說就是橫向擴展，在不更改代碼的情況通過添加機器來提高運算能力。通過添加新的機器向zookeeper注冊服務(wù)，服務(wù)的提供者多了能服務(wù)的客戶就多了。

dubbo：

是管理中間層的工具，在業(yè)務(wù)層到數(shù)據(jù)倉庫間有非常多服務(wù)的接入和服務(wù)提供者需要調(diào)度，dubbo提供一個框架解決這個問題。

注意這里的dubbo只是一個框架，至于你架子上放什么是完全取決于你的，就像一個汽車骨架，你需要配你的輪子引擎。這個框架中要完成調(diào)度必須要有一個分布式的注冊中心，儲存所有服務(wù)的元數(shù)據(jù)，你可以用zk，也可以用別的，只是大家都用zk。

zookeeper和dubbo的關(guān)系：

Dubbo 的將注冊中心進行抽象，它可以外接不同的存儲媒介給注冊中心提供服務(wù)，有 ZooKeeper，Memcached，Redis 等。

引入了 ZooKeeper 作為存儲媒介，也就把 ZooKeeper 的特性引進來。首先是負載均衡，單注冊中心的承載能力是有限的，在流量達到一定程度的時 候就需要分流，負載均衡就是為了分流而存在的，一個 ZooKeeper 群配合相應(yīng)的 Web 應(yīng)用就可以很容易達到負載均衡；資源同步，單單有負載均衡還不 夠，節(jié)點之間的數(shù)據(jù)和資源需要同步，ZooKeeper 集群就天然具備有這樣的功能；命名服務(wù)，將樹狀結(jié)構(gòu)用于維護全局的服務(wù)地址列表，服務(wù)提供者在啟動 的時候，向 ZooKeeper 上的指定節(jié)點 /dubbo/${serviceName}/providers 目錄下寫入自己的 URL 地址，這個操作就完成了服務(wù)的發(fā)布。?其他特性還有 Mast 選舉，分布式鎖等。

出處：https://blog.csdn.net/ThinkWon/article/details/104397719

ZooKeeper 分布式

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。