作者|?ThinkWon

責編 |?Carol

出品 | CSDN云計算（ID：CSDNcloud）

金三銀四，雖然受疫情影響，大多數企業還未正式復工，但沒有條件，創造條件也要上，許多企業已經開始物色合適的人才了，我們怎么能掉隊？趁著在家里，趕緊預習一下面試題，只要一復工，馬上就開始“打仗”了！

今天給大家帶來的是 2020 年最新版的?ZooKeeper?面試題，快收藏慢慢看！

ZooKeeper 是什么？

ZooKeeper 是一個開源的分布式協調服務。它是一個為分布式應用提供一致性服務的軟件，分布式應用程序可以基于 Zookeeper 實現諸如數據發布/訂閱、負載均衡、命名服務、分布式協調/通知、集群管理、Master 選舉、分布式鎖和分布式隊列等功能。

ZooKeeper 的目標就是封裝好復雜易出錯的關鍵服務，將簡單易用的接口和性能高效、功能穩定的系統提供給用戶。

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

順序一致性

原子性

單一視圖

可靠性

實時性（最終一致性）

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

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

ZooKeeper 提供了什么？

• 文件系統

• 通知機制

Zookeeper 文件系統

Zookeeper 提供一個多層級的節點命名空間（節點稱為 znode）。與文件系統不同的是，這些節點都可以設置關聯的數據，而文件系統中只有文件節點可以存放數據而目錄節點不行。

Zookeeper 為了保證高吞吐和低延遲，在內存中維護了這個樹狀的目錄結構，這種特性使得 Zookeeper 不能用于存放大量的數據，每個節點的存放數據上限為1M。

Zookeeper 怎么保證主從節點的狀態同步？

Zookeeper 的核心是原子廣播機制，這個機制保證了各個 server 之間的同步。實現這個機制的協議叫做 Zab 協議。Zab 協議有兩種模式，它們分別是恢復模式和廣播模式。

1、恢復模式

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

2、廣播模式

一旦 leader 已經和多數的 follower 進行了狀態同步后，它就可以開始廣播消息了，即進入廣播狀態。這時候當一個 server 加入 ZooKeeper 服務中，它會在恢復模式下啟動，發現 leader，并和 leader 進行狀態同步。待到同步結束，它也參與消息廣播。ZooKeeper 服務一直維持在 Broadcast 狀態，直到 leader 崩潰了或者 leader 失去了大部分的 followers 支持。

四種類型的數據節點 Znode

1、PERSISTENT-持久節點

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

2、EPHEMERAL-臨時節點

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

3、PERSISTENT_SEQUENTIAL-持久順序節點

基本特性同持久節點，只是增加了順序屬性，節點名后邊會追加一個由父節點維護的自增整型數字。

4、EPHEMERAL_SEQUENTIAL-臨時順序節點

基本特性同臨時節點，增加了順序屬性，節點名后邊會追加一個由父節點維護的自增整型數字。

Zookeeper Watcher 機制 – 數據變更通知

Zookeeper 允許客戶端向服務端的某個 Znode 注冊一個 Watcher 監聽，當服務端的一些指定事件觸發了這個 Watcher，服務端會向指定客戶端發送一個事件通知來實現分布式的通知功能，然后客戶端根據 Watcher 通知狀態和事件類型做出業務上的改變。

工作機制：

客戶端注冊 watcher

服務端處理 watcher

客戶端回調 watcher

Watcher 特性總結：

• 一次性
  

無論是服務端還是客戶端，一旦一個 Watcher 被 觸 發 ，Zookeeper 都會將其從相應的存儲中移除。這樣的設計有效的減輕了服務端的壓力，不然對于更新非常頻繁的節點，服務端會不斷的向客戶端發送事件通知，無論對于網絡還是服務端的壓力都非常大。

• 客戶端串行執行

客戶端 Watcher 回調的過程是一個串行同步的過程。

• 輕量

1）Watcher 通知非常簡單，只會告訴客戶端發生了事件，而不會說明事件的具體內容。

2）客戶端向服務端注冊 Watcher 的時候，并不會把客戶端真實的 Watcher 對象實體傳遞到服務端，僅僅是在客戶端請求中使用 boolean 類型屬性進行了標記。

• watcher event 異步發送 watcher 的通知事件從 server 發送到 client 是異步的。

這就存在一個問題，不同的客戶端和服務器之間通過 socket 進行通信，由于網絡延遲或其他因素導致客戶端在不通的時刻監聽到事件，由于 Zookeeper 本身提供了 ordering guarantee，即客戶端監聽事件后，才會感知它所監視 znode發生了變化。所以我們使用 Zookeeper 不能期望能夠監控到節點每次的變化。Zookeeper 只能保證最終的一致性，而無法保證強一致性。

• 注冊 watcher getData、exists、getChildren

• 觸發 watcher create、delete、setData

• 當一個客戶端連接到一個新的服務器上時，watch 將會被以任意會話事件觸發。

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

客戶端注冊 Watcher 實現

調用 getData()/getChildren()/exist()三個 API，傳入 Watcher 對象

標記請求 request，封裝 Watcher 到 WatchRegistration

封裝成 Packet 對象，發服務端發送 request

收到服務端響應后，將 Watcher 注冊到 ZKWatcherManager 中進行管理

請求返回，完成注冊。

服務端處理 Watcher 實現

• 服務端接收 Watcher 并存儲
  

接收到客戶端請求，處理請求判斷是否需要注冊 Watcher，需要的話將數據節點的節點路徑和 ServerCnxn（ServerCnxn 代表一個客戶端和服務端的連接，實現了 Watcher 的 process 接口，此時可以看成一個 Watcher 對象）存儲在WatcherManager 的 WatchTable 和 watch2Paths 中去。

• Watcher 觸發

以服務端接收到 setData() 事務請求觸發 NodeDataChanged 事件為例：

1）封裝 WatchedEvent

將通知狀態（SyncConnected）、事件類型（NodeDataChanged）以及節點路徑封裝成一個 WatchedEvent 對象

2）查詢 Watcher

從 WatchTable 中根據節點路徑查找 Watcher

3）沒找到；說明沒有客戶端在該數據節點上注冊過 Watcher

4）找到；提取并從 WatchTable 和 Watch2Paths 中刪除對應 Watcher（從這里可以看出 Watcher 在服務端是一次性的，觸發一次就失效了）

• 調用 process 方法來觸發 Watcher

這里 process 主要就是通過 ServerCnxn 對應的 TCP 連接發送 Watcher 事件通知。

客戶端回調 Watcher

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

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

ACL 權限控制機制

UGO（User/Group/Others）

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

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

包括三個方面：

1、權限模式（Scheme）

（1）IP：從 IP 地址粒度進行權限控制

（2）Digest：最常用，用類似于 username:password 的權限標識來進行權限配置，便于區分不同應用來進行權限控制

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

（4）Super：超級用戶

2、授權對象

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

3、權限 Permission

（1）CREATE：數據節點創建權限，允許授權對象在該 Znode 下創建子節點

（2）DELETE：子節點刪除權限，允許授權對象刪除該數據節點的子節點

（3）READ：數據節點的讀取權限，允許授權對象訪問該數據節點并讀取其數據內容或子節點列表等

（4）WRITE：數據節點更新權限，允許授權對象對該數據節點進行更新操作

（5）ADMIN：數據節點管理權限，允許授權對象對該數據節點進行 ACL 相關設置操作

Chroot 特性

3.2.0 版本后，添加了 Chroot 特性，該特性允許每個客戶端為自己設置一個命名空間。如果一個客戶端設置了 Chroot，那么該客戶端對服務器的任何操作，都將會被限制在其自己的命名空間下。

通過設置 Chroot，能夠將一個客戶端應用于 Zookeeper 服務端的一顆子樹相對應，在那些多個應用公用一個 Zookeeper 進群的場景下，對實現不同應用間的相互隔離非常有幫助。

會話管理

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

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

計算公式：

ExpirationTime_ = currentTime + sessionTimeout

ExpirationTime = (ExpirationTime_ / ExpirationInrerval + 1) *

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

服務器角色

• Leader

（1）事務請求的唯一調度和處理者，保證集群事務處理的順序性

（2）集群內部各服務的調度者

• Follower

（1）處理客戶端的非事務請求，轉發事務請求給 Leader 服務器

（2）參與事務請求 Proposal 的投票

（3）參與 Leader 選舉投票

• Observer

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

（2）處理客戶端的非事務請求，轉發事務請求給 Leader 服務器

（3）不參與任何形式的投票

Zookeeper 下 Server 工作狀態

服務器具有四種狀態，分別是 LOOKING、FOLLOWING、LEADING、OBSERVING。

1、LOOKING：尋 找 Leader 狀態。當服務器處于該狀態時，它會認為當前集群中沒有 Leader，因此需要進入 Leader 選舉狀態。

2、FOLLOWING：跟隨者狀態。表明當前服務器角色是 Follower。

3、LEADING：領導者狀態。表明當前服務器角色是 Leader。

4、OBSERVING：觀察者狀態。表明當前服務器角色是 Observer。

數據同步

整個集群完成 Leader 選舉之后，Learner（Follower 和 Observer 的統稱）回向Leader 服務器進行注冊。當 Learner 服務器想 Leader 服務器完成注冊后，進入數據同步環節。

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

Learner 向 Learder 注冊

數據同步

同步確認

Zookeeper 的數據同步通常分為四類：

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

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

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

4、全量同步（SNAP 同步）

在進行數據同步前，Leader 服務器會完成數據同步初始化：

peerLastZxid：

• 從 learner 服務器注冊時發送的 ACKEPOCH 消息中提取 lastZxid（該Learner 服務器最后處理的 ZXID）

minCommittedLog：

• Leader 服務器 Proposal 緩存隊列 committedLog 中最小 ZXIDmaxCommittedLog：

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

• 場景：peerLastZxid 介于 minCommittedLog 和 maxCommittedLog之間先回滾再差異化同步（TRUNC+DIFF 同步）
  

• 場景：當新的 Leader 服務器發現某個 Learner 服務器包含了一條自己沒有的事務記錄，那么就需要讓該 Learner 服務器進行事務回滾–回滾到 Leader服務器上存在的，同時也是最接近于 peerLastZxid 的 ZXID僅回滾同步（TRUNC 同步）
  

• 場景：peerLastZxid 大于 maxCommittedLog
  

全量同步（SNAP 同步）

• 場景一：peerLastZxid 小于 minCommittedLog
  

• 場景二：Leader 服務器上沒有 Proposal 緩存隊列且 peerLastZxid 不等于 lastProcessZxid
  

zookeeper 是如何保證事務的順序一致性的？

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

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

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

zk 節點宕機如何處理？

Zookeeper 本身也是集群，推薦配置不少于 3 個服務器。Zookeeper 自身也要保證當一個節點宕機時，其他節點會繼續提供服務。

如果是一個 Follower 宕機，還有 2 臺服務器提供訪問，因為 Zookeeper 上的數據是有多個副本的，數據并不會丟失；

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

ZK 集群的機制是只要超過半數的節點正常，集群就能正常提供服務。只有在 ZK節點掛得太多，只剩一半或不到一半節點能工作，集群才失效。

所以：

• 3 個節點的 cluster 可以掛掉 1 個節點(leader 可以得到 2 票>1.5)

• 2 個節點的 cluster 就不能掛掉任何 1 個節點了(leader 可以得到 1 票<=1)

zookeeper 負載均衡和 nginx 負載均衡區別

zk 的負載均衡是可以調控，nginx 只是能調權重，其他需要可控的都需要自己寫插件；但是 nginx 的吞吐量比 zk 大很多，應該說按業務選擇用哪種方式。

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

Zookeeper 有三種部署模式：

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

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

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

集群最少要幾臺機器，集群規則是怎樣的？集群中有 3 臺服務器，其中一個節點宕機，這個時候 Zookeeper 還可以使用嗎？

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

集群支持動態添加機器嗎？

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

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

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

3.5 版本開始支持動態擴容。

Zookeeper 對節點的 watch 監聽通知是永久的嗎？為什么不是永久的?

不是。官方聲明：一個 Watch 事件是一個一次性的觸發器，當被設置了 Watch的數據發生了改變的時候，則服務器將這個改變發送給設置了 Watch 的客戶端，以便通知它們。

為什么不是永久的，舉個例子，如果服務端變動頻繁，而監聽的客戶端很多情況下，每次變動都要通知到所有的客戶端，給網絡和服務器造成很大壓力。

一般是客戶端執行 getData(“/節點 A”,true)，如果節點 A 發生了變更或刪除，客戶端會得到它的 watch 事件，但是在之后節點 A 又發生了變更，而客戶端又沒有設置 watch 事件，就不再給客戶端發送。

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

Zookeeper 的 java 客戶端都有哪些？

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

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

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

說幾個 zookeeper 常用的命令。

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

ZAB 和 Paxos 算法的聯系與區別？

相同點：

1、兩者都存在一個類似于 Leader 進程的角色，由其負責協調多個 Follower 進程的運行

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

3、ZAB 協議中，每個 Proposal 中都包含一個 epoch 值來代表當前的 Leader周期，Paxos 中名字為 Ballot

不同點：

ZAB 用來構建高可用的分布式數據主備系統（Zookeeper），Paxos 是用來構建分布式一致性狀態機系統。

Zookeeper 的典型應用場景

Zookeeper 是一個典型的發布/訂閱模式的分布式數據管理與協調框架，開發人員可以使用它來進行分布式數據的發布和訂閱。

通過對 Zookeeper 中豐富的數據節點進行交叉使用，配合 Watcher 事件通知機制，可以非常方便的構建一系列分布式應用中年都會涉及的核心功能，如：

數據發布/訂閱

負載均衡

命名服務

分布式協調/通知

集群管理

Master 選舉

分布式鎖

分布式隊列

數據發布/訂閱

介紹：數據發布/訂閱系統，即所謂的配置中心，顧名思義就是發布者發布數據供訂閱者進行數據訂閱。

目的：

• 動態獲取數據（配置信息）

• 實現數據（配置信息）的集中式管理和數據的動態更新

• 設計模式

• Push 模式

• Pull 模式

數據（配置信息）特性

• 數據量通常比較小
  

• 數據內容在運行時會發生動態更新
  

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

如：機器列表信息、運行時開關配置、數據庫配置信息等

基于 Zookeeper 的實現方式

• 數據存儲：將數據（配置信息）存儲到 Zookeeper 上的一個數據節點

• 數據獲取：應用在啟動初始化節點從 Zookeeper 數據節點讀取數據，并在該節點上注冊一個數據變更 Watcher
  

• 數據變更：當變更數據時，更新 Zookeeper 對應節點數據，Zookeeper會將數據變更通知發到各客戶端，客戶端接到通知后重新讀取變更后的數據即可。
  

負載均衡：zk 的命名服務

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

分布式通知和協調

對于系統調度來說：操作人員發送通知實際是通過控制臺改變某個節點的狀態，然后 zk 將這些變化發送給注冊了這個節點的 watcher 的所有客戶端。

對于執行情況匯報：每個工作進程都在某個目錄下創建一個臨時節點。并攜帶工作的進度數據，這樣匯總的進程可以監控目錄子節點的變化獲得工作進度的實時的全局情況。

zk 的命名服務（文件系統）

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

zk 的配置管理（文件系統、通知機制）

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

Zookeeper 集群管理（文件系統、通知機制）

所謂集群管理無在乎兩點：是否有機器退出和加入、選舉 master。

對于第一點，所有機器約定在父目錄下創建臨時目錄節點，然后監聽父目錄節點

的子節點變化消息。一旦有機器掛掉，該機器與 zookeeper 的連接斷開，其所創建的臨時目錄節點被刪除，所有其他機器都收到通知：某個兄弟目錄被刪除，于是，所有人都知道：它上船了。

新機器加入也是類似，所有機器收到通知：新兄弟目錄加入，highcount 又有了，對于第二點，我們稍微改變一下，所有機器創建臨時順序編號目錄節點，每次選取編號最小的機器作為 master 就好。

Zookeeper 分布式鎖（文件系統、通知機制）

有了 zookeeper 的一致性文件系統，鎖的問題變得容易。鎖服務可以分為兩類，一個是保持獨占，另一個是控制時序。

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

對于第二類， /distribute_lock 已經預先存在，所有客戶端在它下面創建臨時順序編號目錄節點，和選 master 一樣，編號最小的獲得鎖，用完刪除，依次方便。

Zookeeper 隊列管理（文件系統、通知機制）

兩種類型的隊列：

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

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

第一類，在約定目錄下創建臨時目錄節點，監聽節點數目是否是我們要求的數目。

第二類，和分布式鎖服務中的控制時序場景基本原理一致，入列有編號，出列按編號。在特定的目錄下創建 PERSISTENT_SEQUENTIAL 節點，創建成功時Watcher 通知等待的隊列，隊列刪除序列號最小的節點用以消費。此場景下Zookeeper 的 znode 用于消息存儲，znode 存儲的數據就是消息隊列中的消息內容，SEQUENTIAL 序列號就是消息的編號，按序取出即可。由于創建的節點是持久化的，所以不必擔心隊列消息的丟失問題。

Zookeeper 都有哪些功能？

集群管理：監控節點存活狀態、運行請求等；

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

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

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

說一下 Zookeeper 的通知機制？

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

Zookeeper 和 Dubbo 的關系？

Zookeeper的作用：

zookeeper用來注冊服務和進行負載均衡，哪一個服務由哪一個機器來提供必需讓調用者知道，簡單來說就是ip地址和服務名稱的對應關系。當然也可以通過硬編碼的方式把這種對應關系在調用方業務代碼中實現，但是如果提供服務的機器掛掉調用者無法知曉，如果不更改代碼會繼續請求掛掉的機器提供服務。

zookeeper通過心跳機制可以檢測掛掉的機器并將掛掉機器的ip和服務對應關系從列表中刪除。至于支持高并發，簡單來說就是橫向擴展，在不更改代碼的情況通過添加機器來提高運算能力。通過添加新的機器向zookeeper注冊服務，服務的提供者多了能服務的客戶就多了。

dubbo：

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

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

zookeeper和dubbo的關系：

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

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

31 條 2020 年最新版的?ZooKeeper 面試題，看到這里你還不點贊+收藏？

CSDNx巨杉大學聯合認證學習，免費開放！“分布式數據庫集訓營”幫助您從零開始學習分布式數據庫、分布式架構知識，現在加入活動，完成課程還將專屬禮品。快來參加吧~

了解詳情：http://www.sequoiadb.com/cn/university-camp

推薦閱讀：RabbitMQ VS Kafka：消息隊列與流處理平臺之爭 Spark環境搭建——HA高可用模式 | 博文精選 啥？不讓一塊芯片流向華為？ 我們需要什么樣的數據架構？ 隱身術？登頂 GitHub Top1：200 行 JS 代碼讓畫面人物瞬間消失！ 對稱、非對稱公鑰加密是如何工作的？ 真香，朕在看了！點擊“閱讀原文”，即可報名

總結

以上是生活随笔為你收集整理的超级干货！31 条2020 年最新版 ZooKeeper面试题，先收藏再看！| 博文精选的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。