Zookeeper的基本概念與應用場景

ZooKeeper 是一種分佈式協調服務，用於管理大型主機。在分佈式環境中協調和管理服務是一個複雜的過程。ZooKeeper 通過其簡單的架構和 API 解決了這個問題。ZooKeeper 允許開發人員專注於核心應用程序邏輯，而不必擔心應用程序的分佈式特性。

Zookeeper 的數據模型

Zookeeper 的數據模型是什麼樣子呢？它很像數據結構當中的樹，也很像文件系統的目錄。

樹是由節點所組成，Zookeeper 的數據存儲也同樣是基於節點，這種節點叫做 Znode

但是，不同於樹的節點，Znode 的引用方式是路徑引用，類似於文件路徑：

/動物/貓
/汽車/寶馬

這樣的層級結構，讓每一個 Znode 節點擁有唯一的路徑，就像命名空間一樣對不同信息作出清晰的隔離。

Znode 包含哪些元素

• data：Znode 存儲的數據信息。
• ACL：記錄 Znode 的訪問權限，即哪些人或哪些 IP 可以訪問本節點。
• stat：包含 Znode 的各種元數據，比如事務 ID、版本號、時間戳、大小等等。
• child：當前節點的子節點引用

這裏需要注意一點，Zookeeper 是爲讀多寫少的場景所設計。Znode 並不是用來存儲大規模業務數據，而是用於存儲少量的狀態和配置信息，每個節點的數據最大不能超過 1MB。

Zookeeper 的基本操作

創建節點

create

刪除節點

delete

判斷節點是否存在

exists

獲得一個節點的數據

getData

設置一個節點的數據

setData

獲取節點下的所有子節點

getChildren

這其中，exists，getData，getChildren 屬於讀操作。Zookeeper 客戶端在請求讀操作的時候，可以選擇是否設置 Watch

Zookeeper 的事件通知

我們可以把 Watch 理解成是註冊在特定 Znode 上的觸發器。當這個 Znode 發生改變，也就是調用了 create，delete，setData方法的時候，將會觸發 Znode 上註冊的對應事件，請求 Watch 的客戶端會接收到異步通知。

具體交互過程如下：

• 客戶端調用 getData 方法，watch 參數是 true。服務端接到請求，返回節點數據，並且在對應的哈希表裏插入被 Watch 的 Znode 路徑，以及 Watcher 列表。
  
• 當被 Watch 的 Znode 已刪除，服務端會查找哈希表，找到該 Znode 對應的所有 Watcher，異步通知客戶端，並且刪除哈希表中對應的 Key-Value。
  

Zookeeper 的一致性

Zookeeper 身爲分佈式系統協調服務，如果自身掛了如何處理呢？爲了防止單機掛掉的情況，Zookeeper 維護了一個集羣。如下圖：

Zookeeper Service 集羣是一主多從結構。

在更新數據時，首先更新到主節點（這裏的節點是指服務器，不是 Znode），再同步到從節點。

在讀取數據時，直接讀取任意從節點。

爲了保證主從節點的數據一致性，Zookeeper 採用了ZAB協議，這種協議非常類似於一致性算法 Paxos 和 Raft。

什麼是 ZAB

Zookeeper Atomic Broadcast，有效解決了Zookeeper 集羣崩潰恢復，以及主從同步數據的問題。

ZAB 協議定義的三種節點狀態:

• Looking ：選舉狀態。
• Following ：Follower 節點（從節點）所處的狀態。
• Leading ：Leader 節點（主節點）所處狀態。

最大 ZXID

最大 ZXID 也就是節點本地的最新事務編號，包含 epoch 和計數兩部分。epoch 是紀元的意思，相當於 Raft 算法選主時候的 term。

ZAB 的崩潰恢復

假如 Zookeeper 當前的主節點掛掉了，集羣會進行崩潰恢復。ZAB 的崩潰恢復分成三個階段：

• Leader election

選舉階段，此時集羣中的節點處於 Looking 狀態。它們會各自向其他節點發起投票，投票當中包含自己的服務器 ID 和最新事務 ID（ZXID）。

接下來，節點會用自身的 ZXID 和從其他節點接收到的 ZXID 做比較，如果發現別人家的 ZXID 比自己大，也就是數據比自己新，那麼就重新發起投票，投票給目前已知最大的 ZXID 所屬節點。

每次投票後，服務器都會統計投票數量，判斷是否有某個節點得到半數以上的投票。如果存在這樣的節點，該節點將會成爲準 Leader，狀態變爲 Leading。其他節點的狀態變爲 Following。

• Discovery
  發現階段，用於在從節點中發現最新的 ZXID 和事務日誌。或許有人會問：既然 Leader 被選爲主節點，已經是集羣裏數據最新的了，爲什麼還要從節點中尋找最新事務呢？

這是爲了防止某些意外情況，比如因網絡原因在上一階段產生多個 Leader 的情況。

所以這一階段，Leader 集思廣益，接收所有 Follower 發來各自的最新 epoch 值。Leader 從中選出最大的 epoch，基於此值加 1，生成新的 epoch 分發給各個 Follower。

各個 Follower 收到全新的 epoch 後，返回 ACK 給 Leader，帶上各自最大的 ZXID 和歷史事務日誌。Leader 選出最大的 ZXID，並更新自身歷史日誌。

• Synchronization
  同步階段，把 Leader 剛纔收集得到的最新歷史事務日誌，同步給集羣中所有的 Follower。只有當半數 Follower 同步成功，這個準 Leader 才能成爲正式的 Leader。

自此，故障恢復正式完成。

ZAB 的數據寫入

Broadcast
ZAB 的數據寫入涉及到 Broadcast 階段，簡單來說，就是 Zookeeper 常規情況下更新數據的時候，由 Leader 廣播到所有的 Follower。其過程如下：

• 客戶端發出寫入數據請求給任意 Follower。
• Follower 把寫入數據請求轉發給 Leader。
• Leader 採用二階段提交方式，先發送 Propose 廣播給 Follower。
• Follower 接到 Propose 消息，寫入日誌成功後，返回 ACK 消息給 Leader。
• Leader 接到半數以上ACK消息，返回成功給客戶端，並且廣播 Commit 請求給 Follower
  
  ZAB 協議既不是強一致性，也不是弱一致性，而是處於兩者之間的單調一致性（順序一致性）。它依靠事務 ID 和版本號，保證了數據的更新和讀取是有序的。

Zookeeper 的應用場景

分佈式鎖

這是雅虎研究員設計 Zookeeper 的初衷。利用 Zookeeper 的臨時順序節點，可以輕鬆實現分佈式鎖。

服務註冊和發現

利用 Znode 和 Watcher，可以實現分佈式服務的註冊和發現。最著名的應用就是阿里的分佈式 RPC 框架 Dubbo。

共享配置和狀態信息

Redis 的分佈式解決方案 Codis，就利用了 Zookeeper 來存放數據路由表和 codis-proxy 節點的元信息。同時 codis-config 發起的命令都會通過 ZooKeeper 同步到各個存活的 codis-proxy。

此外，Kafka、HBase、Hadoop，也都依靠Zookeeper同步節點信息，實現高可用。