­

大白話帶你認識 ZooKeeper ！重要概念一網打盡！

大家好，我是 「後端技術進階」 作者，一個熱愛技術的少年。

1. 前言

相信大家對 ZooKeeper 應該不算陌生。但是你真的了解 ZooKeeper 到底有啥用不？如果別人/面試官讓你給他講講對於 ZooKeeper 的認識，你能回答到什麼地步呢？

拿我自己來說吧！我本人曾經使用 Dubbo 來做分散式項目的時候，使用了 ZooKeeper 作為註冊中心。為了保證分散式系統能夠同步訪問某個資源，我還使用 ZooKeeper 做過分散式鎖。另外，我在學習 Kafka 的時候，知道 Kafka 很多功能的實現依賴了 ZooKeeper。

前幾天，總結項目經驗的時候，我突然問自己 ZooKeeper 到底是個什麼東西？想了半天，腦海中只是簡單的能浮現出幾句話：

  1. ZooKeeper 可以被用作註冊中心、分散式鎖；
  2. ZooKeeper 是 Hadoop 生態系統的一員；
  3. 構建 ZooKeeper 集群的時候，使用的伺服器最好是奇數台。

由此可見，我對於 ZooKeeper 的理解僅僅是停留在了表面。

所以，通過本文，希望帶大家稍微詳細的了解一下 ZooKeeper 。如果沒有學過 ZooKeeper ，那麼本文將會是你進入 ZooKeeper 大門的墊腳磚。如果你已經接觸過 ZooKeeper ，那麼本文將帶你回顧一下 ZooKeeper 的一些基礎概念。

另外，本文不光會涉及到 ZooKeeper 的一些概念，後面的文章會介紹到 ZooKeeper 常見命令的使用以及使用 Apache Curator 作為 ZooKeeper 的客戶端。

如果文章有任何需要改善和完善的地方，歡迎在評論區指出，共同進步！

2. ZooKeeper 介紹

2.1. ZooKeeper 由來

正式介紹 ZooKeeper 之前，我們先來看看 ZooKeeper 的由來，還挺有意思的。

下面這段內容摘自《從 Paxos 到 ZooKeeper 》第四章第一節，推薦大家閱讀一下：

ZooKeeper 最早起源於雅虎研究院的一個研究小組。在當時，研究人員發現，在雅虎內部很多大型系統基本都需要依賴一個類似的系統來進行分散式協調，但是這些系統往往都存在分散式單點問題。所以，雅虎的開發人員就試圖開發一個通用的無單點問題的分散式協調框架，以便讓開發人員將精力集中在處理業務邏輯上。

關於「ZooKeeper」這個項目的名字，其實也有一段趣聞。在立項初期，考慮到之前內部很多項目都是使用動物的名字來命名的（例如著名的 Pig 項目),雅虎的工程師希望給這個項目也取一個動物的名字。時任研究院的首席科學家 RaghuRamakrishnan 開玩笑地說：「在這樣下去，我們這兒就變成動物園了！」此話一出，大家紛紛表示就叫動物園管理員吧一一一因為各個以動物命名的分散式組件放在一起，雅虎的整個分散式系統看上去就像一個大型的動物園了，而 ZooKeeper 正好要用來進行分散式環境的協調一一於是，ZooKeeper 的名字也就由此誕生了。

2.2. ZooKeeper 概覽

ZooKeeper 是一個開源的分散式協調服務，它的設計目標是將那些複雜且容易出錯的分散式一致性服務封裝起來，構成一個高效可靠的原語集，並以一系列簡單易用的介面提供給用戶使用。

原語： 作業系統或電腦網路用語範疇。是由若干條指令組成的，用於完成一定功能的一個過程。具有不可分割性·即原語的執行必須是連續的，在執行過程中不允許被中斷。

ZooKeeper 為我們提供了高可用、高性能、穩定的分散式數據一致性解決方案，通常被用於實現諸如數據發布/訂閱、負載均衡、命名服務、分散式協調/通知、集群管理、Master 選舉、分散式鎖和分散式隊列等功能。

另外，ZooKeeper 將數據保存在記憶體中，性能是非常棒的。 在「讀」多於「寫」的應用程式中尤其地高性能，因為「寫」會導致所有的伺服器間同步狀態。（「讀」多於「寫」是協調服務的典型場景）。

2.3. ZooKeeper 特點

  • 順序一致性： 從同一客戶端發起的事務請求，最終將會嚴格地按照順序被應用到 ZooKeeper 中去。
  • 原子性： 所有事務請求的處理結果在整個集群中所有機器上的應用情況是一致的，也就是說，要麼整個集群中所有的機器都成功應用了某一個事務，要麼都沒有應用。
  • 單一系統映像 ： 無論客戶端連到哪一個 ZooKeeper 伺服器上，其看到的服務端數據模型都是一致的。
  • 可靠性： 一旦一次更改請求被應用，更改的結果就會被持久化，直到被下一次更改覆蓋。

2.4. ZooKeeper 典型應用場景

ZooKeeper 概覽中，我們介紹到使用其通常被用於實現諸如數據發布/訂閱、負載均衡、命名服務、分散式協調/通知、集群管理、Master 選舉、分散式鎖和分散式隊列等功能。

下面選 3 個典型的應用場景來專門說說：

  1. 分散式鎖 ： 通過創建唯一節點獲得分散式鎖，當獲得鎖的一方執行完相關程式碼或者是掛掉之後就釋放鎖。
  2. 命名服務 ：可以通過 ZooKeeper 的順序節點生成全局唯一 ID
  3. 數據發布/訂閱 ：通過 Watcher 機制 可以很方便地實現數據發布/訂閱。當你將數據發布到 ZooKeeper 被監聽的節點上，其他機器可通過監聽 ZooKeeper 上節點的變化來實現配置的動態更新。

實際上，這些功能的實現基本都得益於 ZooKeeper 可以保存數據的功能，但是 ZooKeeper 不適合保存大量數據，這一點需要注意。

2.5. 有哪些著名的開源項目用到了 ZooKeeper?

  1. Kafka : ZooKeeper 主要為 Kafka 提供 Broker 和 Topic 的註冊以及多個 Partition 的負載均衡等功能。
  2. Hbase : ZooKeeper 為 Hbase 提供確保整個集群只有一個 Master 以及保存和提供 regionserver 狀態資訊（是否在線）等功能。
  3. Hadoop : ZooKeeper 為 Namenode 提供高可用支援。

3. ZooKeeper 重要概念解讀

破音：拿出小本本，下面的內容非常重要哦！

3.1. Data model（數據模型）

ZooKeeper 數據模型採用層次化的多叉樹形結構，每個節點上都可以存儲數據，這些數據可以是數字、字元串或者是二級制序列。並且。每個節點還可以擁有 N 個子節點，最上層是根節點以「/」來代表。每個數據節點在 ZooKeeper 中被稱為 znode，它是 ZooKeeper 中數據的最小單元。並且，每個 znode 都一個唯一的路徑標識。

強調一句：ZooKeeper 主要是用來協調服務的，而不是用來存儲業務數據的，所以不要放比較大的數據在 znode 上，ZooKeeper 給出的上限是每個結點的數據大小最大是 1M。

從下圖可以更直觀地看出：ZooKeeper 節點路徑標識方式和 Unix 文件系統路徑非常相似，都是由一系列使用斜杠”/”進行分割的路徑表示，開發人員可以向這個節點中寫人數據，也可以在節點下面創建子節點。這些操作我們後面都會介紹到。

ZooKeeper 數據模型

3.2. znode（數據節點）

介紹了 ZooKeeper 樹形數據模型之後，我們知道每個數據節點在 ZooKeeper 中被稱為 znode，它是 ZooKeeper 中數據的最小單元。你要存放的數據就放在上面，是你使用 ZooKeeper 過程中經常需要接觸到的一個概念。

3.2.1. znode 4種類型

我們通常是將 znode 分為 4 大類：

  • 持久（PERSISTENT）節點 ：一旦創建就一直存在即使 ZooKeeper 集群宕機，直到將其刪除。
  • 臨時（EPHEMERAL）節點 ：臨時節點的生命周期是與 客戶端會話（session） 綁定的，會話消失則節點消失 。並且，臨時節點只能做葉子節點 ，不能創建子節點。
  • 持久順序（PERSISTENT_SEQUENTIAL）節點 ：除了具有持久（PERSISTENT）節點的特性之外， 子節點的名稱還具有順序性。比如 /node1/app0000000001 、/node1/app0000000002 。
  • 臨時順序（EPHEMERAL_SEQUENTIAL）節點 ：除了具備臨時（EPHEMERAL）節點的特性之外，子節點的名稱還具有順序性。

3.2.2. znode 數據結構

每個 znode 由 2 部分組成:

  • stat ：狀態資訊
  • data ： 節點存放的數據的具體內容

如下所示，我通過 get 命令來獲取 根目錄下的 dubbo 節點的內容。（get 命令在下面會介紹到）。

[zk: 127.0.0.1:2181(CONNECTED) 6] get /dubbo
# 該數據節點關聯的數據內容為空
null
# 下面是該數據節點的一些狀態資訊，其實就是 Stat 對象的格式化輸出
cZxid = 0x2
ctime = Tue Nov 27 11:05:34 CST 2018
mZxid = 0x2
mtime = Tue Nov 27 11:05:34 CST 2018
pZxid = 0x3
cversion = 1
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 0
numChildren = 1

Stat 類中包含了一個數據節點的所有狀態資訊的欄位，包括事務 ID-cZxid、節點創建時間-ctime 和子節點個數-numChildren 等等。

下面我們來看一下每個 znode 狀態資訊究竟代表的是什麼吧！（下面的內容來源於《從 Paxos 到 ZooKeeper 分散式一致性原理與實踐》，因為 Guide 確實也不是特別清楚，要學會參考資料的嘛！ ） ：

znode 狀態資訊 解釋
cZxid create ZXID，即該數據節點被創建時的事務 id
ctime create time，即該節點的創建時間
mZxid modified ZXID，即該節點最終一次更新時的事務 id
mtime modified time，即該節點最後一次的更新時間
pZxid 該節點的子節點列表最後一次修改時的事務 id，只有子節點列表變更才會更新 pZxid，子節點內容變更不會更新
cversion 子節點版本號，當前節點的子節點每次變化時值增加 1
dataVersion 數據節點內容版本號，節點創建時為 0，每更新一次節點內容(不管內容有無變化)該版本號的值增加 1
aclVersion 節點的 ACL 版本號，表示該節點 ACL 資訊變更次數
ephemeralOwner 創建該臨時節點的會話的 sessionId；如果當前節點為持久節點，則 ephemeralOwner=0
dataLength 數據節點內容長度
numChildren 當前節點的子節點個數

3.3. 版本（version）

在前面我們已經提到，對應於每個 znode，ZooKeeper 都會為其維護一個叫作 Stat 的數據結構，Stat 中記錄了這個 znode 的三個相關的版本：

  • dataVersion ：當前 znode 節點的版本號
  • cversion ： 當前 znode 子節點的版本
  • aclVersion ： 當前 znode 的 ACL 的版本。

3.4. ACL（許可權控制）

ZooKeeper 採用 ACL（AccessControlLists）策略來進行許可權控制，類似於 UNIX 文件系統的許可權控制。

對於 znode 操作的許可權，ZooKeeper 提供了以下 5 種：

  • CREATE : 能創建子節點
  • READ ：能獲取節點數據和列出其子節點
  • WRITE : 能設置/更新節點數據
  • DELETE : 能刪除子節點
  • ADMIN : 能設置節點 ACL 的許可權

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

對於身份認證，提供了以下幾種方式：

  • world ： 默認方式，所有用戶都可無條件訪問。
  • auth :不使用任何 id，代表任何已認證的用戶。
  • digest :用戶名:密碼認證方式： username:password 。
  • ip : 對指定 ip 進行限制。

3.5. Watcher（事件監聽器）

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

破音：非常有用的一個特性，都能出小本本記好了，後面用到 ZooKeeper 基本離不開 Watcher（事件監聽器）機制。

3.6. 會話（Session）

Session 可以看作是 ZooKeeper 伺服器與客戶端的之間的一個 TCP 長連接，通過這個連接，客戶端能夠通過心跳檢測與伺服器保持有效的會話，也能夠向 ZooKeeper 伺服器發送請求並接受響應，同時還能夠通過該連接接收來自伺服器的 Watcher 事件通知。

Session 有一個屬性叫做：sessionTimeout ，sessionTimeout 代表會話的超時時間。當由於伺服器壓力太大、網路故障或是客戶端主動斷開連接等各種原因導致客戶端連接斷開時，只要在sessionTimeout規定的時間內能夠重新連接上集群中任意一台伺服器，那麼之前創建的會話仍然有效。

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

4. ZooKeeper 集群

為了保證高可用，最好是以集群形態來部署 ZooKeeper，這樣只要集群中大部分機器是可用的（能夠容忍一定的機器故障），那麼 ZooKeeper 本身仍然是可用的。通常 3 台伺服器就可以構成一個 ZooKeeper 集群了。ZooKeeper 官方提供的架構圖就是一個 ZooKeeper 集群整體對外提供服務。

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

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

4.1. ZooKeeper 集群角色

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

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

角色 說明
Leader 為客戶端提供讀和寫的服務，負責投票的發起和決議，更新系統狀態。
Follower 為客戶端提供讀服務，如果是寫服務則轉發給 Leader。在選舉過程中參與投票。
Observer 為客戶端提供讀伺服器，如果是寫服務則轉發給 Leader。不參與選舉過程中的投票，也不參與「過半寫成功」策略。在不影響寫性能的情況下提升集群的讀性能。此角色於 ZooKeeper3.3 系列新增的角色。

當 Leader 伺服器出現網路中斷、崩潰退出與重啟等異常情況時，就會進入 Leader 選舉過程，這個過程會選舉產生新的 Leader 伺服器。

這個過程大致是這樣的：

  1. Leader election（選舉階段）：節點在一開始都處於選舉階段，只要有一個節點得到超半數節點的票數，它就可以當選准 leader。
  2. Discovery（發現階段） ：在這個階段，followers 跟准 leader 進行通訊，同步 followers 最近接收的事務提議。
  3. Synchronization（同步階段） :同步階段主要是利用 leader 前一階段獲得的最新提議歷史，同步集群中所有的副本。同步完成之後
    准 leader 才會成為真正的 leader。
  4. Broadcast（廣播階段） :到了這個階段，ZooKeeper 集群才能正式對外提供事務服務，並且 leader 可以進行消息廣播。同時如果有新的節點加入，還需要對新節點進行同步。

4.2. ZooKeeper 集群中的伺服器狀態

  • LOOKING ：尋找 Leader。
  • LEADING ：Leader 狀態，對應的節點為 Leader。
  • FOLLOWING ：Follower 狀態，對應的節點為 Follower。
  • OBSERVING ：Observer 狀態，對應節點為 Observer，該節點不參與 Leader 選舉。

4.3. ZooKeeper 集群為啥最好奇數台？

ZooKeeper 集群在宕掉幾個 ZooKeeper 伺服器之後，如果剩下的 ZooKeeper 伺服器個數大於宕掉的個數的話整個 ZooKeeper 才依然可用。假如我們的集群中有 n 台 ZooKeeper 伺服器，那麼也就是剩下的服務數必須大於 n/2。先說一下結論，2n 和 2n-1 的容忍度是一樣的，都是 n-1，大家可以先自己仔細想一想，這應該是一個很簡單的數學問題了。
比如假如我們有 3 台，那麼最大允許宕掉 1 台 ZooKeeper 伺服器，如果我們有 4 台的的時候也同樣只允許宕掉 1 台。
假如我們有 5 台，那麼最大允許宕掉 2 台 ZooKeeper 伺服器，如果我們有 6 台的的時候也同樣只允許宕掉 2 台。

綜上，何必增加那一個不必要的 ZooKeeper 呢？

5. ZAB 協議和Paxos 演算法

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

5.1. ZAB 協議介紹

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

5.2. ZAB 協議兩種基本的模式：崩潰恢復和消息廣播

ZAB 協議包括兩種基本的模式，分別是

  • 崩潰恢復 ：當整個服務框架在啟動過程中，或是當 Leader 伺服器出現網路中斷、崩潰退出與重啟等異常情況時，ZAB 協議就會進入恢復模式並選舉產生新的Leader伺服器。當選舉產生了新的 Leader 伺服器，同時集群中已經有過半的機器與該Leader伺服器完成了狀態同步之後，ZAB協議就會退出恢復模式。其中，所謂的狀態同步是指數據同步，用來保證集群中存在過半的機器能夠和Leader伺服器的數據狀態保持一致。
  • 消息廣播 ：當集群中已經有過半的Follower伺服器完成了和Leader伺服器的狀態同步，那麼整個服務框架就可以進入消息廣播模式了。 當一台同樣遵守ZAB協議的伺服器啟動後加入到集群中時，如果此時集群中已經存在一個Leader伺服器在負責進行消息廣播，那麼新加入的伺服器就會自覺地進入數據恢復模式：找到Leader所在的伺服器，並與其進行數據同步，然後一起參與到消息廣播流程中去。

關於 ZAB 協議&Paxos演算法 需要講和理解的東西太多了，具體可以看下面這兩篇文章：

6. 總結

  1. ZooKeeper 本身就是一個分散式程式（只要半數以上節點存活，ZooKeeper 就能正常服務）。
  2. 為了保證高可用，最好是以集群形態來部署 ZooKeeper，這樣只要集群中大部分機器是可用的（能夠容忍一定的機器故障），那麼 ZooKeeper 本身仍然是可用的。
  3. ZooKeeper 將數據保存在記憶體中，這也就保證了 高吞吐量和低延遲（但是記憶體限制了能夠存儲的容量不太大，此限制也是保持 znode 中存儲的數據量較小的進一步原因）。
  4. ZooKeeper 是高性能的。 在「讀」多於「寫」的應用程式中尤其地明顯，因為「寫」會導致所有的伺服器間同步狀態。（「讀」多於「寫」是協調服務的典型場景。）
  5. ZooKeeper 有臨時節點的概念。 當創建臨時節點的客戶端會話一直保持活動，瞬時節點就一直存在。而當會話終結時，瞬時節點被刪除。持久節點是指一旦這個 znode 被創建了，除非主動進行 znode 的移除操作，否則這個 znode 將一直保存在 ZooKeeper 上。
  6. ZooKeeper 底層其實只提供了兩個功能：① 管理（存儲、讀取）用戶程式提交的數據；② 為用戶程式提供數據節點監聽服務。

7. 參考

  1. 《從 Paxos 到 ZooKeeper 分散式一致性原理與實踐》

Tags:

VirMach 便宜 VPS

QNews

QNews