可能是全網把 ZooKeeper 概念講的最清楚的一篇文章

在為客戶端建立會話之前，服務端首先會為每個客戶端都分配一個sessionID。由於 sessionID 是 Zookeeper 會話的一個重要標識，許多與會話相關的執行機制都是基於這個 sessionID 的，因此，無論是哪臺伺服器為客戶端分配的 sessionID，都務必保證全域性唯一。

2.3 Znode

在談到分散式的時候，我們通常說的“節點"是指組成叢集的每一臺機器。然而，在Zookeeper中，“節點"分為兩類，第一類同樣是指構成叢集的機器，我們稱之為機器節點；第二類則是指資料模型中的資料單元，我們稱之為資料節點一一ZNode。

Zookeeper將所有資料儲存在記憶體中，資料模型是一棵樹（Znode Tree)，由斜槓（/）的進行分割的路徑，就是一個Znode，例如/foo/path1。每個上都會儲存自己的資料內容，同時還會儲存一系列屬性資訊。

在Zookeeper中，node可以分為持久節點和臨時節點兩類。所謂持久節點是指一旦這個ZNode被建立了，除非主動進行ZNode的移除操作，否則這個ZNode將一直儲存在Zookeeper上。而臨時節點就不一樣了，它的生命週期和客戶端會話系結，一旦客戶端會話失效，那麼這個客戶端建立的所有臨時節點都會被移除。另外，ZooKeeper還允許使用者為每個節點新增一個特殊的屬性：SEQUENTIAL.一旦節點被標記上這個屬性，那麼在這個節點被建立的時候，Zookeeper會自動在其節點名後面追加上一個整型數字，這個整型數字是一個由父節點維護的自增數字。

2.4 版本

在前面我們已經提到，Zookeeper 的每個 ZNode 上都會儲存資料，對應於每個ZNode，Zookeeper 都會為其維護一個叫作 Stat 的資料結構，Stat中記錄了這個 ZNode 的三個資料版本，分別是version（當前ZNode的版本）、cversion（當前ZNode子節點的版本）和 cversion（當前ZNode的ACL版本）。

2.5 Watcher

Watcher（事件監聽器），是Zookeeper中的一個很重要的特性。Zookeeper允許使用者在指定節點上註冊一些Watcher，並且在一些特定事件觸發的時候，ZooKeeper服務端會將事件通知到感興趣的客戶端上去，該機制是Zookeeper實現分散式協調服務的重要特性。

2.6 ACL

Zookeeper採用ACL（AccessControlLists）策略來進行許可權控制，類似於 UNIX 檔案系統的許可權控制。Zookeeper 定義瞭如下5種許可權。

其中尤其需要註意的是，CREATE和DELETE這兩種許可權都是針對子節點的許可權控制。

三 ZooKeeper 特點

• 順序一致性： 從同一客戶端發起的事務請求，最終將會嚴格地按照順序被應用到 ZooKeeper 中去。

• 原子性： 所有事務請求的處理結果在整個叢集中所有機器上的應用情況是一致的，也就是說，要麼整個叢集中所有的機器都成功應用了某一個事務，要麼都沒有應用。

• 單一系統映像 ： 無論客戶端連到哪一個 ZooKeeper 伺服器上，其看到的服務端資料模型都是一致的。

• 可靠性： 一旦一次更改請求被應用，更改的結果就會被持久化，直到被下一次更改改寫。

四 ZooKeeper 設計標的

4.1 簡單的資料模型

ZooKeeper 允許分散式行程透過共享的層次結構名稱空間進行相互協調，這與標準檔案系統類似。 名稱空間由 ZooKeeper 中的資料暫存器組成 - 稱為znode，這些類似於檔案和目錄。 與為儲存設計的典型檔案系統不同，ZooKeeper資料儲存在記憶體中，這意味著ZooKeeper可以實現高吞吐量和低延遲。

4.2 可構建叢集

為了保證高可用，最好是以叢集形態來部署 ZooKeeper，這樣只要叢集中大部分機器是可用的（能夠容忍一定的機器故障），那麼zookeeper本身仍然是可用的。 客戶端在使用 ZooKeeper 時，需要知道叢集機器串列，透過與叢集中的某一臺機器建立 TCP 連線來使用服務，客戶端使用這個TCP連結來傳送請求、獲取結果、獲取監聽事件以及傳送心跳包。如果這個連線異常斷開了，客戶端可以連線到另外的機器上。

ZooKeeper 官方提供的架構圖：

上圖中每一個Server代表一個安裝Zookeeper服務的伺服器。組成 ZooKeeper 服務的伺服器都會在記憶體中維護當前的伺服器狀態，並且每臺伺服器之間都互相保持著通訊。叢集間透過 Zab 協議（Zookeeper Atomic Broadcast）來保持資料的一致性。

4.3 順序訪問

對於來自客戶端的每個更新請求，ZooKeeper 都會分配一個全域性唯一的遞增編號，這個編號反應了所有事務操作的先後順序，應用程式可以使用 ZooKeeper 這個特性來實現更高層次的同步原語。 這個編號也叫做時間戳——zxid（Zookeeper Transaction Id）

4.4 高效能

ZooKeeper 是高效能的。 在“讀”多於“寫”的應用程式中尤其地高效能，因為“寫”會導致所有的伺服器間同步狀態。（“讀”多於“寫”是協調服務的典型場景。）

五 ZooKeeper 叢集角色介紹

最典型叢集樣式： Master/Slave 樣式（主備樣式）。在這種樣式中，通常 Master伺服器作為主伺服器提供寫服務，其他的 Slave 伺服器從伺服器透過非同步複製的方式獲取 Master 伺服器最新的資料提供讀服務。

但是，在 ZooKeeper 中沒有選擇傳統的  Master/Slave 概念，而是引入了Leader、Follower 和 Observer 三種角色。如下圖所示

ZooKeeper 叢集中的所有機器透過一個 Leader 選舉過程來選定一臺稱為 “Leader” 的機器，Leader 既可以為客戶端提供寫服務又能提供讀服務。除了 Leader 外，Follower 和  Observer 都只能提供讀服務。Follower 和  Observer 唯一的區別在於 Observer 機器不參與 Leader 的選舉過程，也不參與寫操作的“過半寫成功”策略，因此 Observer 機器可以在不影響寫效能的情況下提升叢集的讀效能。

當 Leader 伺服器出現網路中斷、崩潰退出與重啟等異常情況時，ZAB 協議就會進人恢復樣式並選舉產生新的Leader伺服器。這個過程大致是這樣的：

1. Leader election（選舉階段）：節點在一開始都處於選舉階段，只要有一個節點得到超半數節點的票數，它就可以當選準 leader。

2. Discovery（發現階段）：在這個階段，followers 跟準 leader 進行通訊，同步 followers 最近接收的事務提議。

3. Synchronization（同步階段）:同步階段主要是利用 leader 前一階段獲得的最新提議歷史，同步叢集中所有的副本。同步完成之後 準 leader 才會成為真正的 leader。

4. Broadcast（廣播階段） ：到了這個階段，Zookeeper 叢集才能正式對外提供事務服務，並且 leader 可以進行訊息廣播。同時如果有新的節點加入，還需要對新節點進行同步。

六 ZooKeeper &ZAB; 協議&Paxos;演演算法

6.1 ZAB 協議&Paxos;演演算法

Paxos 演演算法應該可以說是  ZooKeeper 的靈魂了。但是，ZooKeeper 並沒有完全採用 Paxos演演算法 ，而是使用 ZAB 協議作為其保證資料一致性的核心演演算法。另外，在ZooKeeper的官方檔案中也指出，ZAB協議並不像 Paxos 演演算法那樣，是一種通用的分散式一致性演演算法，它是一種特別為Zookeeper設計的崩潰可恢復的原子訊息廣播演演算法。

6.2 ZAB 協議介紹

ZAB（ZooKeeper Atomic Broadcast 原子廣播） 協議是為分散式協調服務 ZooKeeper 專門設計的一種支援崩潰恢復的原子廣播協議。 在 ZooKeeper 中，主要依賴 ZAB 協議來實現分散式資料一致性，基於該協議，ZooKeeper 實現了一種主備樣式的系統架構來保持叢集中各個副本之間的資料一致性。

6.3 ZAB 協議兩種基本的樣式：崩潰恢復和訊息廣播

ZAB協議包括兩種基本的樣式，分別是 崩潰恢復和訊息廣播。當整個服務框架在啟動過程中，或是當 Leader 伺服器出現網路中斷、崩潰退出與重啟等異常情況時，ZAB 協議就會進人恢復樣式並選舉產生新的Leader伺服器。當選舉產生了新的 Leader 伺服器，同時叢集中已經有過半的機器與該Leader伺服器完成了狀態同步之後，ZAB協議就會退出恢復樣式。其中，所謂的狀態同步是指資料同步，用來保證叢集中存在過半的機器能夠和Leader伺服器的資料狀態保持一致。

當叢集中已經有過半的Follower伺服器完成了和Leader伺服器的狀態同步，那麼整個服務框架就可以進人訊息廣播樣式了。 當一臺同樣遵守ZAB協議的伺服器啟動後加人到叢集中時，如果此時叢集中已經存在一個Leader伺服器在負責進行訊息廣播，那麼新加人的伺服器就會自覺地進人資料恢復樣式：找到Leader所在的伺服器，並與其進行資料同步，然後一起參與到訊息廣播流程中去。正如上文介紹中所說的，ZooKeeper設計成只允許唯一的一個Leader伺服器來進行事務請求的處理。Leader伺服器在接收到客戶端的事務請求後，會生成對應的事務提案併發起一輪廣播協議；而如果叢集中的其他機器接收到客戶端的事務請求，那麼這些非Leader伺服器會首先將這個事務請求轉發給Leader伺服器。

關於 ZAB 協議&Paxos;演演算法 需要講和理解的東西太多了，說實話，筆主到現在不太清楚這倆兄弟的具體原理和實現過程。推薦閱讀下麵兩篇文章：

• 圖解 Paxos 一致性協議:

  http://blog.xiaohansong.com/2016/09/30/Paxos/

• Zookeeper ZAB 協議分析:

  http://blog.xiaohansong.com/2016/08/25/zab/

關於如何使用 zookeeper 實現分散式鎖，可以檢視下麵這篇文章：

• Zookeeper ZAB 協議分析:

  https://blog.csdn.net/qiangcuo6087/article/details/79067136

六 總結

透過閱讀本文，想必大家已從 

1. ZooKeeper的由來 。

2. ZooKeeper 到底是什麼 。

3. ZooKeeper 的一些重要概念（會話（Session）、 Znode、版本、Watcher、ACL）

4. ZooKeeper 的特點。

5. ZooKeeper 的設計標的。

6. ZooKeeper 叢集角色介紹 （Leader、Follower 和 Observer 三種角色）

7. ZooKeeper &ZAB; 協議&Paxos;演演算法。

這七點瞭解了 ZooKeeper 。

參考

• 《從Paxos到Zookeeper 》

• https://cwiki.apache.org/confluence/display/ZOOKEEPER/ProjectDescription

• https://cwiki.apache.org/confluence/display/ZOOKEEPER/Index

• https://www.cnblogs.com/raphael5200/p/5285583.html

• https://zhuanlan.zhihu.com/p/30024403