摘要：具有不可分割性即原語的執(zhí)行必須是連續(xù)的，在執(zhí)行過程中不允許被中斷。提供服務(wù)主要就是通過數(shù)據(jù)結(jié)構(gòu)原語集機制達(dá)到的。子節(jié)點的版本號數(shù)據(jù)節(jié)點版本號版本號創(chuàng)建該節(jié)點的會話的。后位則為遞增序列。

最近加入了部門的技術(shù)興趣小組，被分配了Zookeeper的研究任務(wù)。在研究過程當(dāng)中，發(fā)現(xiàn)Zookeeper由于其開源的特性和其卓越的性能特點，在業(yè)界使用廣泛，有很多的應(yīng)用場景，而這些不同的應(yīng)用場景實際上底層的原理都是差不多的，只要你真正理解了Zookeeper的一些基礎(chǔ)概念和機制，就能夠觸類旁通。

于是乎，在第一次和項目小組內(nèi)成員分享過Zookeeper作為服務(wù)注冊中心的原理和客戶端demo演示之后，我萌生出了整理一個專題的想法，以此為起點，慢慢撿起自己的博客分享之路。

本篇的內(nèi)容主要介紹以下幾點：

What is Zookeeper

Zookeeper 數(shù)據(jù)模型

Zookeeper 服務(wù)基本操作

Sessions

Watches

總結(jié)

我最早接觸Zookeeper是因為我們項目使用的微服務(wù)治理架構(gòu)是Dubbo，Dubbo推薦使用的服務(wù)注冊中心就是Zookeeper。從本質(zhì)上來說，Zookeeper就是一種分布式協(xié)調(diào)服務(wù)，在分布式環(huán)境中協(xié)調(diào)和管理服務(wù)是一個復(fù)雜的過程。ZooKeeper通過其簡單的架構(gòu)和API解決了這個問題。 ZooKeeper允許開發(fā)人員專注于核心應(yīng)用程序邏輯，而不必?fù)?dān)心應(yīng)用程序的分布式特性。Zookeeper最早的應(yīng)用是在Hadoop生態(tài)中，Apache HBase使用ZooKeeper跟蹤分布式數(shù)據(jù)的狀態(tài)。

實際上從它的名字上就很好理解，Zoo - 動物園，Keeper - 管理員，動物園中有很多種動物，這里的動物就可以比作分布式環(huán)境下多種多樣的服務(wù)，而Zookeeper做的就是管理這些服務(wù)。

ZooKeeper 的設(shè)計目標(biāo)是將那些復(fù)雜且容易出錯的分布式一致性服務(wù)封裝起來，構(gòu)成一個高效可靠的原語集，并以一系列簡單易用的接口提供給用戶使用。

原語： 操作系統(tǒng)或計算機網(wǎng)絡(luò)用語范疇。是由若干條指令組成的，用于完成一定功能的一個過程。具有不可分割性·即原語的執(zhí)行必須是連續(xù)的，在執(zhí)行過程中不允許被中斷。

Zookeeper提供服務(wù)主要就是通過：數(shù)據(jù)結(jié)構(gòu) + 原語集 + watch機制達(dá)到的。

分布式應(yīng)用程序結(jié)合Zookeeper可以實現(xiàn)諸如數(shù)據(jù)發(fā)布/訂閱、負(fù)載均衡、命名服務(wù)、分布式協(xié)調(diào)/通知、集群管理、Master選舉、分布式鎖和分布式隊列等功能。

從上圖可以看到，Zookeeper的數(shù)據(jù)模型和Unix的文件系統(tǒng)目錄樹很類似，擁有一個層次的命名空間。這里面的每一個節(jié)點都被稱為 - ZNode， 節(jié)點可以擁有子節(jié)點，同時也允許少量數(shù)據(jù)節(jié)點存儲在該節(jié)點之下。（可以理解成一個允許一個文件也可以是一個目錄的文件系統(tǒng)）

ZNode通過路徑引用，如同Unix中的文件路徑。路徑必須是絕對的，因此他們必須有斜杠字符/來開頭,除此之外，路徑名必須是唯一的，且不能更改。

這個特性在Dubbo的服務(wù)注冊上也有體現(xiàn)，Dubbo源碼中有個貫穿全局的類URL，dubbo是以總線模式來時刻傳遞和保存配置信息的，也就是配置信息都被放在URL上進行傳遞，隨時可以取得相關(guān)配置信息。Dubbo在向注冊中心注冊時寫下的節(jié)點名就是由URL中的URI和配置信息編碼后組成的。如下圖。

這屬于這部分知識的擴展內(nèi)容，在之后服務(wù)注冊中心的章節(jié)會更具體的說明。

前面提到過，ZNode兼具文件和目錄兩種特點，既像文件一樣維護著數(shù)據(jù)、元信息、ACL、時間戳等數(shù)據(jù)結(jié)構(gòu)，又像目錄一樣可以作為路徑標(biāo)識的一部分。

ZNode由以下幾部分組成：

Stat數(shù)據(jù)結(jié)構(gòu)

操作控制列表（ACL） - 每個節(jié)點都有一個ACL來做節(jié)點的操作控制，這個列表規(guī)定了用戶的權(quán)限，限定了特定用戶對目標(biāo)節(jié)點的操作

CREATE - 創(chuàng)建子節(jié)點的權(quán)限

READ - 獲取節(jié)點數(shù)據(jù)和子節(jié)點列表的權(quán)限

WRITE - 更新節(jié)點數(shù)據(jù)的權(quán)限

DELETE - 刪除子節(jié)點的權(quán)限

ADMIN - 設(shè)置節(jié)點ACL的權(quán)限

版本 - ZNode有三個數(shù)據(jù)版本

version - 當(dāng)前ZNode的版本

cversion - 當(dāng)前ZNode子節(jié)點的版本

aversion - 當(dāng)前ACL列表的版本

Zxid

可以理解成Zookeeper中時間戳的一種表現(xiàn)形式，也可以理解成事務(wù)ID的概念

如果Zxid1的值小于Zxid2的值，那么Zxid1所對應(yīng)的事件發(fā)生在Zxid2所對應(yīng)的事件之前。

ZooKeeper的每個節(jié)點維護者三個Zxid值，分別為：cZxid、mZxid、pZxid。

cZxid：節(jié)點創(chuàng)建時間 create

mZxid：節(jié)點最近一次修改時間 modify

pZxid：該節(jié)點的子節(jié)點列表最后一次被修改時的時間，子節(jié)點內(nèi)容變更不會變更pZxid

data域

children節(jié)點

下面有幾個需要注意的知識點著重講一下：

下圖是我在服務(wù)器上使用zkClient，用get命令獲取到的某個Dubbo微服務(wù)接口節(jié)點的狀態(tài)信息，來作為示例，

[zk: localhost:2181(CONNECTED) 0] get /dubbo/com.***.microservice.ucs.api.UniqueControlApi
127.0.0.1 // 節(jié)點數(shù)據(jù)Data域
cZxid = 0xdd59  //Created ZXID,表示該ZNode被創(chuàng)建時的事務(wù)ID
ctime = Thu Apr 18 15:17:11 CST 2019 //Created Time,表示該ZNode被創(chuàng)建的時間
mZxid = 0xdd59 //Modified ZXID，表示該ZNode最后一次被更新時的事務(wù)ID
mtime = Thu Apr 18 15:17:11 CST 2019 //Modified Time，表示該節(jié)點最后一次被更新的時間
pZxid = 0xdd62 //表示該節(jié)點的子節(jié)點列表最后一次被修改時的事務(wù)ID。注意，只有子節(jié)點列表變更了才會變更pZxid，子節(jié)點內(nèi)容變更不會影響pZxid。
cversion = 4  //子節(jié)點的版本號
dataVersion = 0 //數(shù)據(jù)節(jié)點版本號
aclVersion = 0 //ACL版本號
ephemeralOwner = 0x0  //創(chuàng)建該節(jié)點的會話的sessionID。如果該節(jié)點是持久節(jié)點，那么這個屬性值為0。
dataLength = 9 // Data域內(nèi)容長度 
numChildren = 4 // 子節(jié)點個數(shù) 眾所周知，Dubbo接口子節(jié)點分為providers/configurators/routers/consumers

關(guān)于Data域，Zookeeper中每個節(jié)點存儲的數(shù)據(jù)要被原子性的操作,也就是說讀操作將獲取與節(jié)點相關(guān)的所有數(shù)據(jù)，寫操作也將替換掉節(jié)點的所有數(shù)據(jù)。

值得注意的是，Zookeeper雖然可以存儲數(shù)據(jù)，但是從設(shè)計目的上，并不是為了做數(shù)據(jù)庫或者大數(shù)據(jù)存儲，相反，它是用來管理調(diào)度數(shù)據(jù)，比如分布式應(yīng)用中的配置文件信息、狀態(tài)信息、匯集位置等，這些數(shù)據(jù)通常是很小的數(shù)據(jù)，KB為大小單位。ZNode對數(shù)據(jù)大小也有限制，至多1M。實際上從這里，就可以推導(dǎo)出Zookeeper用于分布式配置中心的可行性。

在ZooKeeper中，能改變ZooKeeper服務(wù)器狀態(tài)的操作稱為事務(wù)操作。一般包括數(shù)據(jù)節(jié)點創(chuàng)建與刪除、數(shù)據(jù)內(nèi)容更新和客戶端會話創(chuàng)建與失效等操作。對應(yīng)每一個事務(wù)請求，ZooKeeper都會為其分配一個全局唯一的事務(wù)ID，用Zxid表示。

由上圖的示例可以看出，Zxid是一個64位的數(shù)字。前32位叫做epoch，用來標(biāo)識Zookeeper 集群中的Leader節(jié)點，當(dāng)Leader節(jié)點更換時，就會有一個新的epoch。后32位則為遞增序列。從這些Zxid中可以間接地識別出ZooKeeper處理這些事務(wù)操作請求的全局順序。

ZNode節(jié)點類型嚴(yán)格來說有四種：持久節(jié)點、臨時節(jié)點、持久順序節(jié)點、臨時順序節(jié)點

PERSISTENT 持久節(jié)點 - 該節(jié)點的生命周期不依賴于session，創(chuàng)建之后客戶端斷開連接，節(jié)點依舊存在，只用客戶端執(zhí)行刪除操作，節(jié)點才能被刪除；

EPHEMERAL 臨時節(jié)點 - 該節(jié)點的聲明周期依賴于session，客戶端斷開連接，臨時節(jié)點就會自動刪除。另外，臨時節(jié)點不允許有子節(jié)點。

SEQUENTIAL 順序節(jié)點 - 當(dāng)選擇創(chuàng)建順序節(jié)點時，ZooKeeper通過將10位的序列號附加到原始名稱來設(shè)置znode的路徑。例如，如果將具有路徑 /myapp 的znode創(chuàng)建為順序節(jié)點，則ZooKeeper會將路徑更改為 /myapp0000000001 ，并將下一個序列號設(shè)置為0000000002。如果兩個順序節(jié)點是同時創(chuàng)建的，那么ZooKeeper不會對每個znode使用相同的數(shù)字。順序節(jié)點在鎖定和同步中起重要作用。

如上圖，標(biāo)明了Zookeeper服務(wù)的九種基本操作，進入ZkClient.sh，使用help，可以看到這幾種操作。

[zk: localhost:2181(CONNECTED) 1] help   
ZooKeeper -server host:port cmd args
    stat path [watch] // 獲取指定節(jié)點的狀態(tài)信息
    set path data [version] // setData操作
    ls path [watch] // 查看某個節(jié)點下的所有子節(jié)點信息
    delquota [-n|-b] path // 刪除節(jié)點配額
    ls2 path [watch] // ls + stat 兩個命令結(jié)合
    setAcl path acl // 設(shè)置ACL
    setquota -n|-b val path // 設(shè)置節(jié)點配額，-n 是限制子節(jié)點個數(shù) -b是限制節(jié)點數(shù)據(jù)長度
    history // 歷史命令
    redo cmdno // 執(zhí)行歷史命令
    printwatches on|off
    delete path [version] // 刪除指定路徑節(jié)點，有子節(jié)點需要先刪除子節(jié)點
    sync path // 同步視圖
    listquota path // 查看節(jié)點配額信息
    rmr path // 刪除節(jié)點及其子節(jié)點
    get path [watch] // 獲取當(dāng)前節(jié)點數(shù)據(jù)內(nèi)容
    create [-s] [-e] path data acl // 創(chuàng)建節(jié)點
    addauth scheme auth
    quit 
    getAcl path // 獲取ACL
    close 
    connect host:port

從命令中可以看到，更新ZooKeeper操作是有限制的。delete或setData必須明確要更新的Znode的版本號，我們可以調(diào)用exists找到。如果版本號不匹配，更新將會失敗。

更新ZooKeeper操作是非阻塞式的。因此客戶端如果失去了一個更新(由于另一個進程在同時更新這個Znode)，他可以在不阻塞其他進程執(zhí)行的情況下，選擇重新嘗試或進行其他操作。

在 ZooKeeper 中，一個客戶端連接是指客戶端和服務(wù)器之間的一個 TCP 長連接。客戶端啟動的時候，首先會與服務(wù)器建立一個 TCP 連接，從第一次連接建立開始，客戶端會話的生命周期也開始了。通過這個連接，客戶端能夠通過心跳檢測與服務(wù)器保持有效的會話，也能夠向Zookeeper服務(wù)器發(fā)送請求并接受響應(yīng)，同時還能夠通過該連接接收來自服務(wù)器的Watch事件通知。

客戶端以特定的時間間隔發(fā)送心跳以保持會話有效。如果ZooKeeper Server Ensembles在超過服務(wù)器開啟時指定的期間（會話超時）都沒有從客戶端接收到心跳，則它會判定客戶端死機。

會話超時通常以毫秒為單位。當(dāng)會話由于任何原因結(jié)束時，在該會話期間創(chuàng)建的臨時節(jié)點也會被刪除。

在我看來，Watches - 監(jiān)聽事件，是Zookeeper中一個很重要的特性，也是實現(xiàn)Zookeeper大多數(shù)功能的核心特性之一。簡單來說， Zookeeper允許Client端在指定節(jié)點上注冊Watches，在某些特定事件觸發(fā)的時候，Zookeeper服務(wù)端會將事件異步通知到感興趣（即注冊了Watches）的客戶端上去。可以理解成一個訂閱/發(fā)布系統(tǒng)，是不是。

Znode更改是與znode相關(guān)的數(shù)據(jù)的修改或znode的子項中的更改。只觸發(fā)一次watches。如果客戶端想要再次通知，則必須通過另一個讀取操作來完成。當(dāng)連接會話過期時，客戶端將與服務(wù)器斷開連接，相關(guān)的watches也將被刪除。

下面說完簡單的，來說點復(fù)雜的部分。

幾個特性先了解下：

One-time trigger 一次watch時間只會被觸發(fā)一遍，如果節(jié)點再次發(fā)生變化，除非之前有重新設(shè)置過watches，不然會收到通知；

Sent to Client 當(dāng)watch的對象狀態(tài)發(fā)生改變時，將會觸發(fā)此對象上watch所對應(yīng)的事件。watch事件將被異步地發(fā)送給客戶端，并且ZooKeeper為watch機制提供了有序的一致性保證(Ordering guarantee)。

The data for which the watch was set 發(fā)送給客戶端的數(shù)據(jù)信息，實際上就是你這個watch監(jiān)視的類型，見下文介紹

Zookeeper的Watches 分為兩種，數(shù)據(jù)監(jiān)聽器（Data Watches）和子節(jié)點監(jiān)聽器（Children Watches）。即你可以對某個節(jié)點的Data設(shè)置watches，也可以對某個子節(jié)點設(shè)置watches。

可以看下Zookeeper Java 客戶端 Zkclient 中的設(shè)置watches的代碼:

// listener 監(jiān)聽器
// path 節(jié)點路徑

// 子節(jié)點監(jiān)聽器
private List addTargetChildListener(String path, IZkChildListener listener) {
    return client.subscribeChildChanges(path, listener);
}

// 節(jié)點數(shù)據(jù)的監(jiān)聽器
public void addChildDataListener(String path, IZkDataListener listener) {
    try {
        // 遞歸創(chuàng)建節(jié)點
        client.subscribeDataChanges(path, listener);
    } catch (ZkNodeExistsException e) {
    }
}

作為開發(fā)者，需要知道監(jiān)控節(jié)點的什么操作會觸發(fā)你設(shè)置的watches。

一個成功的setData操作將觸發(fā)Znode的數(shù)據(jù)watches

一個成功的create操作將觸發(fā)Znode的數(shù)據(jù)watches以及子節(jié)點watches

一個成功的delete操作將觸發(fā)Znode的數(shù)據(jù)watches和子節(jié)點watches

再看下ZkClient中的數(shù)據(jù)監(jiān)聽器接口IZkDataListener

public interface IZkDataListener {
    // 監(jiān)控節(jié)點數(shù)據(jù)更新的時候會觸發(fā) 這段邏輯
    public void handleDataChange(String dataPath, Object data) throws Exception;
    // 監(jiān)控節(jié)點被刪除的時候會觸發(fā) 這段邏輯
    public void handleDataDeleted(String dataPath) throws Exception;
}

再看下ZkClient中的子節(jié)點監(jiān)聽器接口IZkChildListener

public interface IZkChildListener {

    /**
     * Called when the children of the given path changed.
     * 監(jiān)控節(jié)點的子節(jié)點列表改變時會觸發(fā)這段邏輯
     * 
     * @param parentPath
     *            The parent path
     * @param currentChilds
     *            The children or null if the root node (parent path) was deleted.
     * @throws Exception
     */
    public void handleChildChange(String parentPath, List currentChilds) throws Exception;
}

實際上看到這就能聯(lián)想到，Zookeeper是可以當(dāng)做分布式配置中心來使用的，只不過你需要自己擴展他異步通知節(jié)點數(shù)據(jù)變化之后的邏輯，更新你的配置。在后面的章節(jié)會更新相關(guān)demo。

關(guān)于Watches 詳細(xì)介紹可以參考官網(wǎng)的介紹：

ZooKeeper Watches
https://zookeeper.apache.org/...

本章內(nèi)容算是Zookeeper系列的開篇，介紹了Zookeeper的幾個基礎(chǔ)概念，并且給出了相關(guān)實例，助于理解。

現(xiàn)在我們再回過頭來看看Zookeeper的特性：

① 順序一致性
從同一個客戶端發(fā)起的事務(wù)請求，最終將會嚴(yán)格按照其發(fā)起順序被應(yīng)用到ZooKeeper中。
② 原子性
所有事務(wù)請求的結(jié)果在集群中所有機器上的應(yīng)用情況是一致的，也就是說要么整個集群所有集群都成功應(yīng)用了某一個事務(wù)，要么都沒有應(yīng)用，一定不會出現(xiàn)集群中部分機器應(yīng)用了該事務(wù)，而另外一部分沒有應(yīng)用的情況。
③ 單一視圖
無論客戶端連接的是哪個ZooKeeper服務(wù)器，其看到的服務(wù)端數(shù)據(jù)模型都是一致的。
④ 可靠性
一旦服務(wù)端成功地應(yīng)用了一個事務(wù)，并完成對客戶端的響應(yīng)，那么該事務(wù)所引起的服務(wù)端狀態(tài)變更將會被一直保留下來，除非有另一個事務(wù)又對其進行了變更。
⑤ 實時性
通常人們看到實時性的第一反應(yīng)是，一旦一個事務(wù)被成功應(yīng)用，那么客戶端能夠立即從服務(wù)端上讀取到這個事務(wù)變更后的最新數(shù)據(jù)狀態(tài)。這里需要注意的是，ZooKeeper僅僅保證在一定的時間段內(nèi)，客戶端最終一定能夠從服務(wù)端上讀取到最新的數(shù)據(jù)狀態(tài)。

今天的內(nèi)容中，順序一致性是通過ZXid來實現(xiàn)的，全局唯一，順序遞增，同一個session中請求是FIFO的；可靠性的描述也可以通過今天的知識進行理解，一次事務(wù)的應(yīng)用，服務(wù)端狀態(tài)的變更會以Zxid、Znode數(shù)據(jù)版本、數(shù)據(jù)、節(jié)點路徑的形式保存下來。剩下的幾種特性是怎么實現(xiàn)的，在學(xué)習(xí)完Zookeeper集群相關(guān)的內(nèi)容之后應(yīng)該就能理解。

本篇文章中借鑒了網(wǎng)上幾篇優(yōu)秀的文章，并且結(jié)合了我本人一些思考和實踐。希望能對你學(xué)習(xí)了解Zookeeper起到一些幫助。

下一章，我會介紹Zookeeper集群方面的知識，CAP理論在Zookeeper中的實踐，以及如何搭建Zookeeper的集群。

[1] https://zookeeper.apache.org/... 官方文檔（強烈推薦）

[2] https://www.cnblogs.com/sundd... 作者應(yīng)該是對官方文檔有比較深的了解，我發(fā)現(xiàn)他的文章的脈絡(luò)和官網(wǎng)有很相似的地方。寫的非常好

[3] https://www.jianshu.com/p/a17... 作者對Zookeeper做了一個易懂的總體介紹

[4] https://www.w3cschool.cn/zook... w3cSchool tutorial