全網最全Zookeeper面試題（2020最新版）

https://thinkwon.blog.csdn.ne...

1. ZooKeeper 是什麼？

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

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

Zookeeper 保證了以下分佈式一致性特性：

（1）順序一致性

（2）原子性

（3）單一視圖

（4）可靠性

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

客戶端的讀請求能夠被集羣中的任意一臺機器處理，若是讀請求在節點上註冊了監聽器，這個監聽器也是由所鏈接的 zookeeper 機器來處理。對於寫請求，這些請求會同時發給其餘 zookeeper 機器而且達成一致後，請求才會返回成功。所以，隨着 zookeeper 的集羣機器增多，讀請求的吞吐會提升可是寫請求的吞吐會降低。

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

2. ZooKeeper 提供了什麼？

文件系統

通知機制

3. Zookeeper 文件系統

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

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

4. Zookeeper 怎麼保證主從節點的狀態同步？

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

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

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

5. 四種類型的數據節點 Znode

（1）PERSISTENT-持久節點

除非手動刪除，不然節點一直存在於 Zookeeper 上

（2）EPHEMERAL-臨時節點

臨時節點的生命週期與客戶端會話綁定，一旦客戶端會話失效（客戶端與zookeeper 鏈接斷開不必定會話失效），那麼這個客戶端建立的全部臨時節點都會被移除。

（3）PERSISTENT_SEQUENTIAL-持久順序節點

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

（4）EPHEMERAL_SEQUENTIAL-臨時順序節點

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

6. Zookeeper Watcher 機制 – 數據變動通知

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

工做機制：

（1）客戶端註冊 watcher

（2）服務端處理 watcher

（3）客戶端回調 watcher

Watcher 特性總結：

（1）一次性

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

（2）客戶端串行執行

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

（3）輕量

3.一、Watcher 通知很是簡單，只會告訴客戶端發生了事件，而不會說明事件的具體內容。

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

（4）watcher event 異步發送 watcher 的通知事件從 server 發送到 client 是異步的，這就存在一個問題，不一樣的客戶端和服務器之間經過 socket 進行通訊，因爲網絡延遲或其餘因素致使客戶端在不通的時刻監聽到事件，因爲 Zookeeper 自己提供了 ordering guarantee，即客戶端監聽事件後，纔會感知它所監視 znode發生了變化。因此咱們使用 Zookeeper 不能指望可以監控到節點每次的變化。Zookeeper 只能保證最終的一致性，而沒法保證強一致性。

（5）註冊 watcher getData、exists、getChildren

（6）觸發 watcher create、delete、setData

（7）當一個客戶端鏈接到一個新的服務器上時，watch 將會被以任意會話事件觸發。當與一個服務器失去鏈接的時候，是沒法接收到 watch 的。而當 client 從新鏈接時，若是須要的話，全部先前註冊過的 watch，都會被從新註冊。一般這是徹底透明的。只有在一個特殊狀況下，watch 可能會丟失：對於一個未建立的 znode的 exist watch，若是在客戶端斷開鏈接期間被建立了，而且隨後在客戶端鏈接上以前又刪除了，這種狀況下，這個 watch 事件可能會被丟失。

7. 客戶端註冊 Watcher 實現

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

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

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

（4）收到服務端響應後，將 Watcher 註冊到 ZKWatcherManager 中進行管理

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

8. 服務端處理 Watcher 實現

（1）服務端接收 Watcher 並存儲

接收到客戶端請求，處理請求判斷是否須要註冊 Watcher，須要的話將數據節點的節點路徑和 ServerCnxn（ServerCnxn 表明一個客戶端和服務端的鏈接，實現了 Watcher 的 process 接口，此時能夠當作一個 Watcher 對象）存儲在WatcherManager 的 WatchTable 和 watch2Paths 中去。

（2）Watcher 觸發

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

2.1 封裝 WatchedEvent

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

2.2 查詢 Watcher

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

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

2.4 找到；提取並從 WatchTable 和 Watch2Paths 中刪除對應 Watcher（從這裏能夠看出 Watcher 在服務端是一次性的，觸發一次就失效了）

（3）調用 process 方法來觸發 Watcher

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

9. 客戶端回調 Watcher

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

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

10. ACL 權限控制機制

UGO（User/Group/Others）

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

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

包括三個方面：

權限模式（Scheme）

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

（2）Digest：最經常使用，用相似於 username:password 的權限標識來進行權限配置，便於區分不一樣應用來進行權限控制

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

（4）Super：超級用戶

受權對象

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

權限 Permission

（1）CREATE：數據節點建立權限，容許受權對象在該 Znode 下建立子節點

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

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

（4）WRITE：數據節點更新權限，容許受權對象對該數據節點進行更新操做

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

11. Chroot 特性

3.2.0 版本後，添加了 Chroot 特性，該特性容許每一個客戶端爲本身設置一個命名空間。若是一個客戶端設置了 Chroot，那麼該客戶端對服務器的任何操做，都將會被限制在其本身的命名空間下。

經過設置 Chroot，可以將一個客戶端應用於 Zookeeper 服務端的一顆子樹相對應，在那些多個應用公用一個 Zookeeper 進羣的場景下，對實現不一樣應用間的相互隔離很是有幫助。

12. 會話管理

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

分配原則：每一個會話的「下次超時時間點」（ExpirationTime）

計算公式：

ExpirationTime_ = currentTime + sessionTimeout

ExpirationTime = (ExpirationTime_ / ExpirationInrerval + 1) *

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

13. 服務器角色

Leader

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

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

Follower

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

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

（3）參與 Leader 選舉投票

Observer

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

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

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

14. Zookeeper 下 Server 工做狀態

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

（1）LOOKING：尋 找 Leader 狀態。當服務器處於該狀態時，它會認爲當前集羣中沒有 Leader，所以須要進入 Leader 選舉狀態。

（2）FOLLOWING：跟隨者狀態。代表當前服務器角色是 Follower。

（3）LEADING：領導者狀態。代表當前服務器角色是 Leader。

（4）OBSERVING：觀察者狀態。代表當前服務器角色是 Observer。

15. 數據同步

整個集羣完成 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

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

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

17. 分佈式集羣中爲何會有 Master主節點？

在分佈式環境中，有些業務邏輯只須要集羣中的某一臺機器進行執行，其餘的機器能夠共享這個結果，這樣能夠大大減小重複計算，提升性能，因而就須要進行 leader 選舉。

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

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

zk 的負載均衡是能夠調控，nginx 只是能調權重，其餘須要可控的都須要本身寫插件；可是 nginx 的吞吐量比 zk 大不少，應該說按業務選擇用哪一種方式。

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

Zookeeper 有三種部署模式：

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

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

僞集羣部署：一臺集羣啓動多個 Zookeeper 實例運行。

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

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

22. 集羣支持動態添加機器嗎？

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

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

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

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

23. Zookeeper 對節點的 watch 監聽通知是永久的嗎？爲何不是永久的?

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

爲何不是永久的，舉個例子，若是服務端變更頻繁，而監聽的客戶端不少狀況下，每次變更都要通知到全部的客戶端，給網絡和服務器形成很大壓力。

通常是客戶端執行 getData(「/節點 A」,true)，若是節點 A 發生了變動或刪除，客戶端會獲得它的 watch 事件，可是在以後節點 A 又發生了變動，而客戶端又沒有設置 watch 事件，就再也不給客戶端發送。

在實際應用中，不少狀況下，咱們的客戶端不須要知道服務端的每一次變更，我只要最新的數據便可。

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

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

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

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

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

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

27. ZAB 和 Paxos 算法的聯繫與區別？

相同點：

（1）二者都存在一個相似於 Leader 進程的角色，由其負責協調多個 Follower 進程的運行

（2）Leader 進程都會等待超過半數的 Follower 作出正確的反饋後，纔會將一個提案進行提交

（3）ZAB 協議中，每一個 Proposal 中都包含一個 epoch 值來表明當前的 Leader週期，Paxos 中名字爲 Ballot

不一樣點：

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

28. Zookeeper 的典型應用場景

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

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

（1）數據發佈/訂閱

（2）負載均衡

（3）命名服務

（4）分佈式協調/通知

（5）集羣管理

（6）Master 選舉

（7）分佈式鎖

（8）分佈式隊列

數據發佈/訂閱

介紹

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

目的

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

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

設計模式

Push 模式

Pull 模式

數據（配置信息）特性

（1）數據量一般比較小

（2）數據內容在運行時會發生動態更新

（3）集羣中各機器共享，配置一致

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

基於 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 序列號就是消息的編號，按序取出便可。因爲建立的節點是持久化的，因此沒必要擔憂隊列消息的丟失問題。

29. Zookeeper 都有哪些功能？

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

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

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

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

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

client 端會對某個 znode 創建一個 watcher 事件，當該 znode 發生變化時，這些 client 會收到 zk 的通知，而後 client 能夠根據 znode 變化來作出業務上的改變等。

31. 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 選舉，分佈式鎖等。

若有錯誤或其它問題，歡迎小夥伴留言評論、指正。若有幫助，歡迎點贊+轉發分享。

歡迎你們關注民工哥的公衆號：民工哥技術之路