Zookeeper 是一個高性能、高可靠的分布式協調系統，是 Google Chubby 的一個開源實現，目前在分布式系統、大數據領域中使用非常廣泛。本文將介紹 Zookeeper 集群架構、數據模型、監聽機制，以及Zookeeper典型的應用場景等。

1. Zookeeper 集群角色

首先介紹下 Zookeeper 集群，一個 Zookeeper 集群通常由一組機器組成，一般3~5臺集群就可以組成一個 Zookeeper 集群。集群拓撲圖基本如下：

Zookeeper 集群中每一個節點都會在內存中維護當前的節點狀態，并且彼此之間保持著通信。這里說明一點，只要集群中存在過半的節點正常工作，整個集群就能夠對外提供服務。

如上圖，在 Zookeeper 集群中，有 Leader、Follower 和 Observer 三種類型的角色。

Leader

Leader 節點整個 Zookeeper 集群工作機制中的核心，主要工作是處理客戶端的讀寫請求，及集群內部各服務的調度。注意只有 leader 能夠處理寫請求。

Follower

處理客戶端的讀請求，將寫請求轉發給 leader。參與 leader 選舉投票等。

Observer

這是自 Zookeeper 3.3.0 版本引入的一個新的角色，主要是為了解決大規模 Server 場景下因 leader 選舉投票成本增加導致寫性能下降的問題。Observer 的工作原理和 follower 基本一致。處理客戶端的讀請求，將寫請求轉發給leader。和 follower 唯一的區別在于，Observer不參與任何形式的選舉，包括 leader 選舉。一般而言，中小型規模的 Zookeeper 集群中只包含 leader 和 follower 兩個角色，這容易讓我們忽略 observer 角色的存在。配置一個節點為 observer 也很簡單，只需如下兩步：

# 在observer節點的配置文件中添加如下配置 peerType=observer# 在每個節點的配置文件中，給observer節點添加:observer標識 # 例如： server.1:localhost:2181:3181:observer

至此，相信你對 Zookeeper 的集群架構與相關角色有了一定認識。

2. Zookeeper 數據模型

Zookeeper 的數據模型是一棵類似 Unix 文件系統的 ZNode Tree 即 ZNode 樹，但是沒有引入傳統文件系統的目錄或者文件等概念，而是使用了稱為 “數據節點” 的概念，術語叫做 ZNode。ZNode 是 Zookeeper 存儲數據的最小單元，每個 ZNode 可以保存數據，也可以掛載子節點，其中根節點是 /。示意圖如下：

使用過 Zookeeper 的同學應該都知道，Zookeeper 主要提供了兩個核心功能：

• 管理（存儲、讀取）客戶端提交的數據；
• 為客戶端提供數據節點的監聽服務；

這里就涉及到 Zookeeper 的兩個重要特性，就是它的 ZNode 模型與 Watcher 機制。

ZNode 模型

前面講到 Zookeeper 是由數據節點 ZNode 構成的，Zookeeper 中的每個數據節點都是有生命周期的，其生命周期的長短取決于 ZNode 的節點類型。ZNode 根據其生命周期和特點可分為 4 類。

分別是：

• 持久性節點（PERSISTENT）：客戶端與 Zookeeper 斷開會話后，該節點依舊存在，直到執行刪除操作才會清除節點。
• 持久性順序節點（PERSISTENT_SEQUENTIAL）：另一種持久節點，Zookeeper 會給該節點名稱加上一個數字后綴，進行順序編號。
• 臨時節點（EPHEMERAL）：節點的生命周期和客戶端的會話綁定在一起，客戶端與 Zookeeper 斷開會話后，該節點就會被自動刪除。各個場景中很多都是利用 Zookeeper 臨時節點這個特性的。
• 臨時順序節點（EPHEMERAL_SEQUENTIAL）：概念和上面類似，Zookeeper 也會給該節點進行順序編號。

前面提及了 ZNode 是存儲數據的最小單元，除了存儲用戶數據外，ZNode 還有以下特點：

• 包含 ZNode 修改/訪問的時間、事務id（zxid），ACL 權限、版本等狀態信息；
• 所有的事務請求在 ZNode 端都是順序和原子性的；
• 數據主要存儲在內存中，磁盤中保存事務日志、快照數據等；

Watcher 機制

Watcher 機制也稱監聽機制，它是 Zookeeper 的關鍵特性，是通過 ZooKeeper 實現分布式發布/訂閱、分布式鎖、集群管理等功能的基礎。

如上圖所示，Zookeeper 允許客戶端向服務端注冊一個 Watcher 監聽器，當服務端的一些指定事件觸發了該監聽，比如節點創建、刪除，節點數據變更等事件，Zookeeper 就會向注冊了監聽器的客戶端發送相應的事件通知。

3. 代碼演示 Zookeeper 監聽器

接下來我們看一下通過 Zookeeper 原生的客戶端 API，創建 ZNode 數據節點，然后演示下 Zookeeper 監聽器的基本使用。

引入依賴

首先，當前有一個包含3個節點的 Zookeeper 集群，我們根據 Zookeeper 版本引入了相應依賴，如下

<

演示代碼

• 創建 ZNode

private

（可左右滑動）

執行完這個單元測試后，我們通過命令行在服務端查看一下該數據節點：

[zk: localhost:2181(CONNECTED) 48] get /my_node 123 cZxid = 0xdb6439ef2 ctime = Fri Feb 27 21:08:09 CST 2020 mZxid = 0xdb6439ef2 mtime = Fri Feb 27 21:08:09 CST 2020 pZxid = 0xdb6439ef2 cversion = 0 dataVersion = 0 aclVersion = 0 ephemeralOwner = 0x0 dataLength = 3 numChildren = 0

• 刪除 ZNode 節點，并監聽該節點的刪除動作

@Test

（可左右滑動）

代碼執行后，可以看到控制臺打印出了我們的日志：

21:41:07.870 [main-EventThread] INFO xxx - 注意：ZNode '/my_node' is deleted !

服務端查看該節點也已經不存在了：

[zk: localhost:2181(CONNECTED) 50] get /my_node Node does not exist: /my_node

這里我們簡單演示了下 Zookeeper 原始 API、監聽器的使用，希望通過這個簡單的demo，我們能對 Zookeeper 監聽器有一個比較直觀的認識。

4. Zookeeper 應用場景

Zookeeper 在分布式系統、大數據領域里應用廣泛，這里總結了 8 個典型的應用場景：

數據發布/訂閱

即所謂的配置管理或配置中心，拓撲圖如下：

通常在分布式系統或集群中，所以節點的配置應該一致，比如Hadoop集群，要求對配置的修改，能夠快速同步到各個節點中，可以通過 Zookeeper 實現：

• 將配置信息寫入 ZooKeeper 的一個 ZNode 中；
• 各個節點在啟動階段從 Zookeeper 中獲取配置，并注冊一個數據變更的 Watcher 監聽器；
• 當 ZNode 中的數據被修改，ZooKeeper 將通知各個客戶端節點，節點收到通知后進行配置更新；

負載均衡

負載均衡通常是一種動態的服務配置，拓撲圖：

通常包含兩部分：

• 服務注冊，服務提供者啟動時會在某一個根 ZNode 節點下創建屬于自己的子節點，并寫入一些服務信息 比如IP:Port信息；
• 服務解析，服務使用者在請求服務時會先獲取根 ZNode 節點的子節點列表，即服務列表，然后通過一定的負載均衡算法 比如hash選取一個服務訪問；

命名服務

又稱 nameservice，這是比較常見的場景，Zookeeper 的命令服務主要有兩個方向的應用：

• 提供類似 JNDI 的功能：就是把各種服務的名稱，地址及其他信息放到 Zookeeper 中，使用時去讀取，實現資源的定位和使用；
• 利用 Zookeeper 順序節點的特性，生成分布式的全局唯一 ID；

分布式協調/通知

主要是利用了 Zookeeper Watcher 的注冊與異步通知機制，通常的做法是不同客戶端都對 Zookeeper 的一個數據節點進行 Watcher 注冊，監聽數據的變化，當數據節點發生變化時，所有訂閱的客戶端都能接到通知并做相應處理。常見場景比如：

• Master 節點定期檢測 Slave 節點的狀態，類似于心跳檢測機制；
• 信息推送，相當于一個發布訂閱系統，和第一個場景類似；

集群管理

主要包括兩部分功能

• 記錄當前集群中有多少個節點在工作，以及節點的運行狀態；
• 對集群中的節點進行上下線方面的操作；

Master 選舉

Master 選舉是一個分布式系統中非常常見的場景，這里是利用 Zookeeper 的強一致性，保證只有一個客戶端能夠創建節點成功。

分布式鎖

不同節點上的服務，可能需要同時訪問一個資源，這事可能需要一把分布式鎖。使用 Zookeeper 實現分布式鎖主要基于以下特性：

• ZooKeeper 的強一致性，保證只有一個客戶端能夠創建鎖成功。
• 鎖的獨占性，創建 ZNode 成功的客戶端才能得到鎖，其他客戶端只能等待，當客戶端用完釋放鎖時，其他客戶端再次嘗試創建 ZNode，獲取分布式鎖。

分布式隊列

利用 Zookeeper 主要能夠實現兩種分布式隊列：

• 當一個隊列的成員都聚齊時，這個隊列才可用，否則一直等待所有成員到達，這種是同步隊列。 比如一個 job 由多個 task 組成，只有所有 task 完成后，job 才運行完成，可為 job 創建一個 /job 目錄，然后在該目錄下，為每個完成的 task 創建一個臨時的 ZNode，一旦臨時節點數目達到 task 總數，則表明 job 運行完成。
• 利用 Zookeeper 的臨時順序節點特性，實現 FIFO 即先進先出的隊列。

5. 總結

本文介紹了 Zookeeper 的集群架構，ZNode 數據模型，Watcher 監聽機制，以及 Zookeeper 的典型應用場景。Zookeeper 在分布式系統應用非常廣泛，主流的大數據組件比如HDFS、HBase、Kafka等也依靠 Zookeeper 做協調服務。通過本文的介紹，相信我們對 Zookeeper 有了進一步的掌握。

往期文章精選：

1、如何快速全面掌握Kafka？5000字吐血整理

2、一文讀懂 HBase 核心原理與應用場景

3、京東JDHBase異地多活實踐

4、美團點評基于 Flink 的實時數倉平臺實踐

如果您喜歡這篇文章，點【在看】與轉發都是一種鼓勵，期待得到您的認可 ?(^_-)

總結

以上是生活随笔為你收集整理的api 创建zookeeper客户端_一文了解 Zookeeper 基本原理与应用场景的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。