客戶端

znode 可能含有數據，也可能沒有。如果 znode 包含數據，那么數據存儲為字節數組(byte array)。字節數組的具體格式特定于每個應用的實現，ZooKeeper 不直接 提供解析支持。不過一般情況下，以 UTF-8 或 ASCII 編碼的字符串就已經夠用了。

API 概述

ZooKeeper 的 API 可以抽象成以下方法：

create /path data

創建一個名為 /path 的 znode 節點，并包含數據 data

delete /path

刪除名為 /path 的 znode

exists /path

檢查是否存在名為 /path 的節點

setData /path data

設置名為 /path 節點數據為 data

getData /path

返回名為 /path 節點的所有子節點列表

需要注意的是，ZooKepper 并不允許局部寫入或讀取 znode 節點的數據。當設置一個 znode 節點的數據或讀取時，znode 節點的內容會被整個替換或者全部讀取。

zkCli.sh

ZooKeeper 安裝包提供了客戶端工具 zkCli.sh(zkCli.cmd)方便我們學習實驗 API 接口，該工具位于 bin 目錄下，啟動命令格式為：

bin/zkCli.sh -server 127.0.0.1:2181,127.0.0.1:2182,127.0.0.1:2183

后面一段“127.0.0.1:2181,127.0.0.1:2182,127.0.0.1:2183”是 ZooKeeper 集群的 IP 和端口組成的字符串，客戶端會以隨機順序連接到服務器中。連接上集群后，如下圖顯示：

zkCli 連接成功

其中 0x15a0d2841340001 是本次 session 的 id。

這兒簡單的演示臨時節點和監視點特性：

同時開兩個 zkCli 分別為 A，B；

A 連接至 127.0.0.1:2181

A連接到 ZooKeeper 集群

B 連接至 127.0.0.1:2182。

B連接到 ZooKeeper 集群

A 創建臨時節點：create -e /temp_a "temp a znode"

A 創建節點

B 查看節點數據并設置監控點：get /temp_a true

B 查看節點

A 關閉模擬客戶端崩潰。

A 創建的臨時節點被刪除

A 關閉連接

因為監視點的設置，B 收到 /temp_a 刪除通知

B 收到刪除通知

開源客戶端庫

zkCli 只適合學習和試驗 ZooKeeper 集群，如果我們需要利用 ZooKeeper 實際開發分布式協同任務的系統時，可以使用 ZooKeeper 自帶的客戶端庫。不過這些 jar 包只提供基本的阻塞和非阻塞 API 接口，需要開發人員自己實現類似會話超時重連，重復設置監視點等功能。除了 ZooKeeper 自帶的客戶端包，還可以使用以下客戶端模塊。

zkClient

zkClient 是 Github 上一個開源的 ZooKeeper 客戶端，是由 Datameer的工程師 Stefan Groschupf 和 Peter Voss 一起開發的。zkClient 在原生 API 上進行封裝，是一個更簡單易用的 ZooKeeper 客戶端。同時，zkClient 在內部實現了諸如 session 超時重練，Watcher 反復注冊等功能，使這些繁瑣復雜的功能對開發人員透明。

Curator

Curator 是 Netflix 公司開源的一套 ZooKeeper 客戶端框架，和 zkClient 一樣，Curator 解決了很多 ZooKeeper 客戶端非常底層的細節開發工作，目前已成為 Apache 的頂級項目，是全世界范圍內使用最廣泛的 ZooKeeper 客戶端之一。

除了封裝底層細節，使之對開發透明，Curator 還提供了一套易用性和可讀性更強的 Fluent 風格的 API 框架。

除此之外，Curator 還提供餓了 ZooKeeper 各種應用場景的抽象封裝(Recipe)，如共享鎖服務，Master 選舉機制和分布式計數器等。

典型應用

需要再次說明 ZooKeeper 是保證分布式數據一致性和任務協調的框架，它并不會直接實現具體的分布式鎖，Master 選舉等分布式功能，而是提供一些簡單易用的 API 接口，具體的功能實現需要開發者根據情況自行實現。另一方面，ZooKeeper 同時也是一個典型的發布／訂閱模式的分布式數據管理與協調方案，配合監視點事件通知機制，可以非常方便地構建一些列分布式應用中都會涉及的核心功能：

數據發布/訂閱

負載均衡

命名服務

分布式協調/通知

集群管理

Master 選舉

分布式鎖

分布式隊列

下面簡單介紹下分布式鎖的實現思路。

分布式鎖

假設一個應用由 n 個進程組成，分別為 p1, p2 .... pn，這些進程嘗試獲取一個鎖從而進入臨界區進行操作。這兒我們可以使用 ZooKeeper 的 znode 來代表一個鎖，如“/lock”。

所有進程同時嘗試創建這個 znode，由 ZooKeeper 來保證順序性。

如果某進程成功創建了 “/lock”，假設為 p4，則代表 p4 搶占到了該分布式鎖，p4 可以執行臨界區代碼，其他進程則會因為 znode 存在而創建失敗。

它們可以在 “/lock”節點上創建監視器后等待 znode 刪除通知，如果刪除通知到來，則重復 1 搶占鎖。

p4 釋放鎖時，刪除 “/lock”節點即可，需要注意，因為 p4 很可能執行臨界區代碼時崩潰，所以“/lock”節點應該臨時節點，如果 p4 崩潰，則該節點自行刪除。

羊群效應

上述分布式鎖的實現簡單易用，但是卻會造成“羊群效應”。想象一下，如果有 1000 個客戶端同時調用 exists 監視“/lock”節點變化。那么當這個 znode 創建或刪除時就會發送 1000 個通知，這個被監視的 znode 的一個變化會產生一個尖峰的通知，該尖峰時刻提交的操作可能會產生很高的延遲。

為了防止羊群效應的產生，利用有序節點，分布式鎖不妨換一種實現方式：

系統已經存在“/lock”節點，爭搶鎖的進程在該節點下創建臨時有序子節點，形如：/lock/192.168.1.200:2222-00000001;

進程獲取 /lock 下子節點列表，判斷自己的節點位置:

如果自己的節點序號最小，則表示獲得鎖，執行臨界區代碼;

如果不是，則在自己序號前一個子節點增加監視點 Watcher，等待刪除通知。

獲取鎖的進程，執行外臨界代碼，刪除自己的子節點，表示釋放鎖；

下一個子節點序號的進程獲取刪除通知，重復動作 2。

這種實現方式下，進程只監測排在它前面進程的節點，而不是 所有進程都監測 /lock 節點，避免了“羊群效應”。結構如下圖所示：

分布式鎖

ZooKeeper 和 Dubbo

Dubbo 是阿里巴巴開源(好像開源版本已經停止更新)的由 Java 語言編寫的分布式服務框架，致力于提供高性能和透明化的遠程服務調用方案和 SOA 服務治理方案。

Dubbo 基于 ZooKeeper 實現服務注冊中心。注冊中心是 RPC 框架最核心的模塊之一，用于服務的注冊和訂閱。在 Dubbo 的實現中，對注冊中心模塊進行抽象封裝，因此可以基于其提供的外部接口實現各種不同類型的注冊中心，例如數據庫，Redis 等。

在 Dubbo 注冊中心的整體架構中，ZooKeeper 上服務的節點設計如下圖所示：

分布式鎖

/dubbo 這是 Dubbo 在 ZooKeeper 上創建的根節點

/dubbo/com.foo.BarService 是服務節點，代表了 Dubbo 的一個服務

/dubbo/com.foo.BarService/providers 這是服務提供者的根節點，其子節點代表每一個服務真正提供者

/dubbo/com.foo.BarService/consumers 這是服務消費者的根節點，其子節點代表每一個服務的真正消費者

流程說明：

服務提供者(Provider)啟動

向 /dubbo/com.foo.BarService/providers 目錄下寫入自己的URL地址。

服務消費者(Consumer)啟動時

訂閱 /dubbo/com.foo.BarService/providers 目錄下的提供者URL地址。

并向 /dubbo/com.foo.BarService/consumers 目錄下寫入自己的URL地址。

監控中心(Monitor)啟動時

訂閱 /dubbo/com.foo.BarService 目錄下的所有提供者和消費者URL地址。

需要注意的是，所有提供者和消費者在 ZooKeeper 上創建的節點都是臨時節點，利用臨時節點生命周期和會話綁定的特性，一旦機器發生故障導致服務提供者無法對外提供服務，該臨時節點就會自動從 ZooKeeper 上刪除。

內容來源

從 Paxos 到 ZooKeeper 分布式一致性原理與實踐

ZooKeeper 分布式過程協同技術詳解

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的zkcli远程连接_ZooKeeper 学习笔记（二）－API 操作和应用的全部內容，希望文章能夠幫你解決所遇到的問題。

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