當設計一個分佈式系統或微服務架構系統時，一般需要設計和開發一些協調服務。Apache ZooKeeper是一個分佈式、開源的分佈式應用協調服務，也可理解成一個爲分佈式應用提供一致性服務的應用程序，主要作用可簡化分佈式系統搭建及縮短開發週期。ZooKeeper是目前常用的開源解決方案之一。

本文主要針對ZooKeeper的安裝部署、應用場景、開發對接API等，作簡單入門級整理介紹，方便開發人員後續深入研究。

ZooKeeper是什麼？

ZooKeeper 作爲一個分佈式的服務框架，主要用來解決分佈式集羣中應用系統的一致性問題。提供基於類似於文件系統的目錄節點樹方式的數據存儲，ZooKeeper的作用主要是用來維護和監控存儲的數據的狀態變化。通過監控這些數據狀態的變化，從而可以達到基於數據的集羣管理。

ZooKeeper 雖然是一個針對分佈式系統的協調服務，但它本身也是一個分佈式應用程序。ZooKeeper 遵循一個簡單的客戶端-服務器模型。

▲ ZooKeeper 的客戶端-服務器架構

ZooKeeper 有一個類似於文件系統的數據模型，由 znodes 組成。
每個 ZooKeeper 服務器還在磁盤上維護了一個事務日誌，記錄所有的寫入請求。
在啓動 ZooKeeper 服務時，集合體中的某個節點被選舉爲領導者；節點數量應該是奇數。

Zookeeper 從設計模式角度來看，是一個基於觀察者模式設計的分佈式服務管理框架，它負責存儲和管理分佈式應用系統關心的數據，然後接受觀察者的註冊，一旦這些數據的狀態發生變化，Zookeeper 就將負責通知已經註冊的那些觀察者做出相應的反應，從而實現集羣中類似 Master/Slave 管理模式。

常見應用場景

ZooKeeper 是一個面向分佈式系統的構建模塊，下面是當設計一個分佈式系統時，典型的業務應用場景。

01 統一命名服務（Name Service）

命名服務是將一個名稱映射到與該命名有關聯的一些信息的服務。Name Service 已經是 Zookeeper 內置的功能，只要調用 Zookeeper 的 API 就能實現。如調用 create 接口就可以很容易創建一個目錄節點。

02 配置管理（Configuration Management）

配置的管理在分佈式應用環境中很常見，可以使用 ZooKeeper 集中存儲和管理分佈式系統的配置。同時還允許通過其中一個 ZooKeeper 客戶端更改集中式配置，集中地更改分佈式系統的狀態。

03 集羣管理（Group Membership）

Zookeeper 能夠很容易的實現集羣管理的功能，如有多臺 Server 組成一個服務集羣，那麼必須要一個“領導者”知道當前集羣中每臺機器的服務狀態，一旦有機器不能提供服務，集羣中其它集羣必須知道，從而做出調整重新分配服務策略。

04 共享鎖（Locks）

爲了允許在分佈式系統中對共享資源進行有序的訪問，可能需要實現分佈式互斥。ZooKeeper 提供一種簡單的方式來實現它們。

05 隊列管理或同步

針對同步訪問共享資源的需求，無論是實現一個生產者-消費者隊列，還是實現一個障礙，ZooKeeper 都提供一個簡單的接口來實現該操作。Zookeeper 可以處理兩種類型的隊列：

當一個隊列的成員都聚齊時，這個隊列纔可用，否則一直等待所有成員到達，這種是同步隊列。
隊列按照 FIFO 方式進行入隊和出隊操作，例如實現生產者和消費者模型。

安裝配置

01 前提條件

ZooKeeper可以運行在多種系統平臺上面，以下是支持的系統平臺以及在該平臺上是否支持開發環境或者生產環境。

在部署ZooKeeper的機器上需要安裝Java運行環境。爲了正常運行ZooKeeper，我們需要JRE1.6或者以上的版本。

對於集羣模式下的ZooKeeper部署，3個ZooKeeper服務進程是建議的最小進程數量，而且不同的服務進程建議部署在不同的物理機器上面，以減少機器宕機帶來的風險，以實現ZooKeeper集羣的高可用。

02 安裝包說明

ZooKeeper下載地址

下載並解壓ZooKeeper軟件壓縮包後，可以看到ZooKeeper包含以下的文件和目錄：

bin目錄：

ZooKeeper的可執行腳本目錄，包括ZooKeeper服務進程，zk客戶端，等腳本。

conf目錄：

配置文件目錄。zoo_sample.cfg爲樣例配置文件，需要修改爲自己的名稱，一般爲zoo.cfg。log4j.properties爲日誌配置文件。

lib ：

ZooKeeper依賴的包。

contrib目錄：

一些用於操作ZooKeeper的工具包。

recipes目錄：

ZooKeeper某些用法的代碼示例。

03 集羣模式

單機模式的zk進程雖然便於開發與測試，但並不適合在生產環境使用。在生產環境下，我們需要使用集羣模式來對ZooKeeper進行部署。

注意！！！

在集羣模式下，建議至少部署3個zk進程，或者部署奇數個ZooKeeper進程。如果只部署2個ZooKeeper進程，當其中一個ZooKeeper進程掛掉後，剩下的一個進程並不能構成一個Quorum的大多數。因此，部署2個進程甚至比單機模式更不可靠，因爲2個進程其中一個不可用的可能性比一個進程不可用的可能性還大。

運行配置

在集羣模式下，所有的ZooKeeper進程可以使用相同的配置文件（指各個ZooKeeper進程部署在不同的機器上面），例如以下配置：

tickTime=2000

dataDir=/home/myname/zookeeper

clientPort=2181

initLimit=5

syncLimit=2

server.1=192.168.229.160:2888:3888

server.2=192.168.229.161:2888:3888

server.3=192.168.229.162:2888:3888

initLimit :

ZooKeeper集羣模式下包含多個zk進程，其中一個進程爲leader，餘下的進程爲follower。initLimit配置follower與leader之間建立連接後進行同步的最長時間。

syncLimit :

配置follower和leader之間發送消息，請求和應答的最大時間長度。

tickTime :

tickTime則是上述兩個超時配置的基本單位。

server.id=host:port1:port2：

其中id爲一個數字，表示zk進程的id，這個id也是dataDir目錄下myid文件的內容。host是該ZooKeeper進程所在的IP地址，port1表示follower和leader交換消息所使用的端口，port2表示選舉leader所使用的端口。

注意！！！

如果僅爲了測試部署集羣模式而在同一臺機器上部署ZooKeeper進程，server.id=host:port1:port2配置中的port參數必須不同。但是，爲了減少機器宕機的風險，強烈建議在部署集羣模式時，將ZooKeeper進程部署不同的物理機器上面。

啓動

假如我們打算在三臺不同的機器 192.168.229.160，192.168.229.161，192.168.229.162上各部署一個ZooKeeper進程，以構成一個ZooKeeper集羣。三個ZooKeeper進程均使用相同的 zoo.cfg 配置：

tickTime=2000

dataDir=/home/myname/zookeeper

clientPort=2181

initLimit=5

syncLimit=2

server.1=192.168.229.160:2888:3888

server.2=192.168.229.161:2888:3888

server.3=192.168.229.162:2888:3888

在三臺機器dataDir目錄（ /home/myname/zookeeper 目錄）下，分別生成一個myid文件，其內容分別爲1，2，3。然後分別在這三臺機器上啓動ZooKeeper進程，這樣我們便將ZooKeeper集羣啓動了起來。

連接

可以使用以下命令來連接一個ZooKeeper集羣：

bin/zkCli.sh -server 192.168.229.160:2181,192.168.229.161:2181,192.168.229.162:2181

對接API說明

客戶端（以Java爲例）要連接 Zookeeper 服務器可以通過創建 org.apache.zookeeper.ZooKeeper 的一個實例對象，然後調用這個類提供的接口來和服務器交互。接口如下所示：

String create(String path, byte[] data, List<ACL> acl,CreateMode createMode)

創建一個給定目錄節點 path, 並給它設置數據，CreateMode 標識有四種形式的目錄節點，分別是：

PERSISTENT：持久化目錄節點，這個目錄節點存儲的數據不會丟失。
PERSISTENT_SEQUENTIAL：順序自動編號的目錄節點，這種目錄節點會根據當前已存在的節點數自動加 1，然後返回給客戶端已經成功創建的目錄節點名。
EPHEMERAL：臨時目錄節點，一旦創建這個節點的客戶端與服務器端口也就是 session 超時，這種節點會被自動刪除。
EPHEMERAL_SEQUENTIAL：臨時自動編號節點。

Stat exists(String path, boolean watch)

判斷某個 path 是否存在，並設置是否監控這個目錄節點，這裏的 watcher 是在創建 ZooKeeper 實例時指定的 watcher，exists方法還有一個重載方法，可以指定特定的watcher。

Stat exists(String path,Watcher watcher)

重載方法，這裏給某個目錄節點設置特定的 watcher，Watcher 在 ZooKeeper 是一個核心功能，Watcher 可以監控目錄節點的數據變化以及子目錄的變化，一旦這些狀態發生變化，服務器就會通知所有設置在這個目錄節點上的 Watcher，從而每個客戶端都很快知道它所關注的目錄節點的狀態發生變化，而做出相應的反應。

void delete(String path, int version)

刪除 path 對應的目錄節點，version 爲 -1 可以匹配任何版本，也就刪除了這個目錄節點所有數據。

List<String>getChildren(String path, boolean watch)

獲取指定 path 下的所有子目錄節點，同樣 getChildren方法也有一個重載方法可以設置特定的 watcher 監控子節點的狀態。

Stat setData(String path, byte[] data, int version)

給 path 設置數據，可以指定這個數據的版本號，如果 version 爲 -1 怎麼可以匹配任何版本。

byte[] getData(String path, boolean watch, Stat stat)

獲取這個 path 對應的目錄節點存儲的數據，數據的版本等信息可以通過 stat 來指定，同時還可以設置是否監控這個目錄節點數據的狀態。

voidaddAuthInfo(String scheme, byte[] auth)

客戶端將自己的授權信息提交給服務器，服務器將根據這個授權信息驗證客戶端的訪問權限。

Stat setACL(String path,List<ACL> acl, int version)

給某個目錄節點重新設置訪問權限，需要注意的是 Zookeeper 中的目錄節點權限不具有傳遞性，父目錄節點的權限不能傳遞給子目錄節點。目錄節點 ACL 由兩部分組成：perms 和 id。