1.    什麼是ZooKeeper ？

ZooKeeper 是一個開放原始碼的分散式協調服務， 它是叢集的管理者， 監視著叢集中各個節點的狀態根據節點提交的反饋進行下一步合理操作。最終， 將簡單易用的介面和效能高效、功能穩定的系統提供給使用者。

分散式應用程式可以基於  Zookeeper 實現諸如資料釋出/訂閱、負載均衡、命名服務、分散式協調/通知、叢集管理、Master 選舉、分散式鎖和分散式佇列等功能。

Zookeeper 保證瞭如下分散式一致性特性：

1、順序一致性

2、原子性

3、單一檢視

4、可靠性

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

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

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

zookeeper 最新的 zxid。

2.    ZooKeeper 提供了什麼？

1、檔案系統

2、通知機制

3.    Zookeeper 檔案系統

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

Zookeeper 為了保證高吞吐和低延遲， 在記憶體中維護了這個樹狀的目錄結構， 這

種特性使得 Zookeeper 不能用於存放大量的資料， 每個節點的存放資料上限為1M。

4.    ZAB 協議？

ZAB 協議是為分散式協調服務 Zookeeper 專門設計的一種支援崩潰恢復的原子廣播協議。

ZAB 協議包括兩種基本的模式： 崩潰恢復和訊息廣播。

當整個 zookeeper 叢集剛剛啟動或者 Leader 伺服器當機、重啟或者網路故障導致不存在過半的伺服器與 Leader 伺服器保持正常通訊時，所有程式（ 伺服器）進入崩潰恢復模式， 首先選舉產生新的 Leader 伺服器， 然後叢集中 Follower 伺服器開始與新的 Leader 伺服器進行資料同步， 當叢集中超過半數機器與該 Leader 伺服器完成資料同步之後， 退出恢復模式進入訊息廣播模式， Leader 伺服器開始接收客戶端的事務請求生成事物提案來進行事務請求處理。

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.1  、Watcher 通知非常簡單，只會告訴客戶端發生了事件，而不會說明事件的具體內容。

3.2  、客戶端向服務端註冊 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、不參與任何形式的投票

更多福利：

需要更多面試題和學習資料歡迎關注B哥的公眾號：Java2B（微信搜尋）