摘要：除此之外，它嚴(yán)格的序列訪問控制意味著復(fù)雜的控制原語可以應(yīng)用在客戶端上。版本號(hào)對(duì)節(jié)點(diǎn)的每一個(gè)操作都將致使這個(gè)節(jié)點(diǎn)的版本號(hào)增加。事件是一次性的觸發(fā)器，當(dāng)?shù)膶?duì)象狀態(tài)發(fā)生改變時(shí)，將會(huì)觸發(fā)此對(duì)象上所對(duì)應(yīng)的事件。節(jié)點(diǎn)事件節(jié)點(diǎn)的建立，刪除，數(shù)據(jù)的修改。

目錄

一、ZooKeeper概述

二、ZooKeeper數(shù)據(jù)模型

三、ZooKeeper服務(wù)中操作

四、Watch觸發(fā)器

五、ZooKeeper應(yīng)用舉例

ZooKeeper是一種為分布式應(yīng)用所設(shè)計(jì)的高可用、高性能且一致的開源協(xié)調(diào)服務(wù)，它提供了一項(xiàng)基本服務(wù)：分布式鎖服務(wù)。由于ZooKeeper的開源特性，后來我們的開發(fā)者在分布式鎖的基礎(chǔ)上，摸索了出了其他的使用方法：配置維護(hù)、組服務(wù)、分布式消息隊(duì)列、分布式通知/協(xié)調(diào)等。

注意：ZooKeeper性能上的特點(diǎn)決定了它能夠用在大型的、分布式的系統(tǒng)當(dāng)中。從可靠性方面來說，它并不會(huì)因?yàn)橐粋€(gè)節(jié)點(diǎn)的錯(cuò)誤而崩潰。除此之外，它嚴(yán)格的序列訪問控制意味著復(fù)雜的控制原語可以應(yīng)用在客戶端上。ZooKeeper在一致性、可用性、容錯(cuò)性的保證，也是ZooKeeper的成功之處，它獲得的一切成功都與它采用的協(xié)議——Zab協(xié)議是密不可分的，這些內(nèi)容將會(huì)在后面介紹。

前面提到了那么多的服務(wù)，比如分布式鎖、配置維護(hù)、組服務(wù)等，那它們是如何實(shí)現(xiàn)的呢，我相信這才是大家關(guān)心的東西。ZooKeeper在實(shí)現(xiàn)這些服務(wù)時(shí)，首先它設(shè)計(jì)一種新的數(shù)據(jù)結(jié)構(gòu)——Znode，然后在該數(shù)據(jù)結(jié)構(gòu)的基礎(chǔ)上定義了一些原語，也就是一些關(guān)于該數(shù)據(jù)結(jié)構(gòu)的一些操作。有了這些數(shù)據(jù)結(jié)構(gòu)和原語還不夠，因?yàn)槲覀兊腪ooKeeper是工作在一個(gè)分布式的環(huán)境下，我們的服務(wù)是通過消息以網(wǎng)絡(luò)的形式發(fā)送給我們的分布式應(yīng)用程序，所以還需要一個(gè)通知機(jī)制——Watcher機(jī)制。那么總結(jié)一下，ZooKeeper所提供的服務(wù)主要是通過：數(shù)據(jù)結(jié)構(gòu)+原語+watcher機(jī)制，三個(gè)部分來實(shí)現(xiàn)的。那么我就從這三個(gè)方面，給大家介紹一下ZooKeeper。

2.1 ZooKeeper數(shù)據(jù)模型Znode

ZooKeeper擁有一個(gè)層次的命名空間，這個(gè)和標(biāo)準(zhǔn)的文件系統(tǒng)非常相似，如下圖2.1、2.2 所示。

從圖中我們可以看出ZooKeeper的數(shù)據(jù)模型，在結(jié)構(gòu)上和標(biāo)準(zhǔn)文件系統(tǒng)的非常相似，都是采用這種樹形層次結(jié)構(gòu)，ZooKeeper樹中的每個(gè)節(jié)點(diǎn)被稱為—Znode。和文件系統(tǒng)的目錄樹一樣，ZooKeeper樹中的每個(gè)節(jié)點(diǎn)可以擁有子節(jié)點(diǎn)。但也有不同之處：

(1) 引用方式

Zonde通過路徑引用，如同Unix中的文件路徑。路徑必須是絕對(duì)的，因此他們必須由斜杠字符來開頭。除此以外，他們必須是唯一的，也就是說每一個(gè)路徑只有一個(gè)表示，因此這些路徑不能改變。在ZooKeeper中，路徑由Unicode字符串組成，并且有一些限制。字符串"/zookeeper"用以保存管理信息，比如關(guān)鍵配額信息。

(2) Znode結(jié)構(gòu)

ZooKeeper命名空間中的Znode，兼具文件和目錄兩種特點(diǎn)。既像文件一樣維護(hù)著數(shù)據(jù)、元信息、ACL、時(shí)間戳等數(shù)據(jù)結(jié)構(gòu)，又像目錄一樣可以作為路徑標(biāo)識(shí)的一部分。圖中的每個(gè)節(jié)點(diǎn)稱為一個(gè)Znode。 每個(gè)Znode由3部分組成:

① stat：此為狀態(tài)信息, 描述該Znode的版本, 權(quán)限等信息

② data：與該Znode關(guān)聯(lián)的數(shù)據(jù)

③ children：該Znode下的子節(jié)點(diǎn)

ZooKeeper雖然可以關(guān)聯(lián)一些數(shù)據(jù)，但并沒有被設(shè)計(jì)為常規(guī)的數(shù)據(jù)庫或者大數(shù)據(jù)存儲(chǔ)，相反的是，它用來管理調(diào)度數(shù)據(jù)，比如分布式應(yīng)用中的配置文件信息、狀態(tài)信息、匯集位置等等。這些數(shù)據(jù)的共同特性就是它們都是很小的數(shù)據(jù)，通常以KB為大小單位。ZooKeeper的服務(wù)器和客戶端都被設(shè)計(jì)為嚴(yán)格檢查并限制每個(gè)Znode的數(shù)據(jù)大小至多1M，但常規(guī)使用中應(yīng)該遠(yuǎn)小于此值。

(3) 數(shù)據(jù)訪問

ZooKeeper中的每個(gè)節(jié)點(diǎn)存儲(chǔ)的數(shù)據(jù)要被原子性的操作。也就是說讀操作將獲取與節(jié)點(diǎn)相關(guān)的所有數(shù)據(jù)，寫操作也將替換掉節(jié)點(diǎn)的所有數(shù)據(jù)。另外，每一個(gè)節(jié)點(diǎn)都擁有自己的ACL(訪問控制列表)，這個(gè)列表規(guī)定了用戶的權(quán)限，即限定了特定用戶對(duì)目標(biāo)節(jié)點(diǎn)可以執(zhí)行的操作。

(4) 節(jié)點(diǎn)類型

ZooKeeper中的節(jié)點(diǎn)有兩種，分別為臨時(shí)節(jié)點(diǎn)和永久節(jié)點(diǎn)。節(jié)點(diǎn)的類型在創(chuàng)建時(shí)即被確定，并且不能改變。

① 臨時(shí)節(jié)點(diǎn)：該節(jié)點(diǎn)的生命周期依賴于創(chuàng)建它們的會(huì)話。一旦會(huì)話(Session)結(jié)束，臨時(shí)節(jié)點(diǎn)將被自動(dòng)刪除，當(dāng)然可以也可以手動(dòng)刪除。雖然每個(gè)臨時(shí)的Znode都會(huì)綁定到一個(gè)客戶端會(huì)話，但他們對(duì)所有的客戶端還是可見的。另外，ZooKeeper的臨時(shí)節(jié)點(diǎn)不允許擁有子節(jié)點(diǎn)。

② 永久節(jié)點(diǎn)：該節(jié)點(diǎn)的生命周期不依賴于會(huì)話，并且只有在客戶端顯示執(zhí)行刪除操作的時(shí)候，他們才能被刪除。

(5) 順序節(jié)點(diǎn)

當(dāng)創(chuàng)建Znode的時(shí)候，用戶可以請(qǐng)求在ZooKeeper的路徑結(jié)尾添加一個(gè)遞增的計(jì)數(shù)。這個(gè)計(jì)數(shù)對(duì)于此節(jié)點(diǎn)的父節(jié)點(diǎn)來說是唯一的，它的格式為"%10d"(10位數(shù)字，沒有數(shù)值的數(shù)位用0補(bǔ)充，例如"0000000001")。當(dāng)計(jì)數(shù)值大于232-1時(shí)，計(jì)數(shù)器將溢出。

(6) 觀察

客戶端可以在節(jié)點(diǎn)上設(shè)置watch，我們稱之為監(jiān)視器。當(dāng)節(jié)點(diǎn)狀態(tài)發(fā)生改變時(shí)(Znode的增、刪、改)將會(huì)觸發(fā)watch所對(duì)應(yīng)的操作。當(dāng)watch被觸發(fā)時(shí)，ZooKeeper將會(huì)向客戶端發(fā)送且僅發(fā)送一條通知，因?yàn)閣atch只能被觸發(fā)一次，這樣可以減少網(wǎng)絡(luò)流量。

2.2 ZooKeeper中的時(shí)間

ZooKeeper有多種記錄時(shí)間的形式，其中包含以下幾個(gè)主要屬性：

(1) Zxid

致使ZooKeeper節(jié)點(diǎn)狀態(tài)改變的每一個(gè)操作都將使節(jié)點(diǎn)接收到一個(gè)Zxid格式的時(shí)間戳，并且這個(gè)時(shí)間戳全局有序。也就是說，也就是說，每個(gè)對(duì)節(jié)點(diǎn)的改變都將產(chǎn)生一個(gè)唯一的Zxid。如果Zxid1的值小于Zxid2的值，那么Zxid1所對(duì)應(yīng)的事件發(fā)生在Zxid2所對(duì)應(yīng)的事件之前。實(shí)際上，ZooKeeper的每個(gè)節(jié)點(diǎn)維護(hù)者三個(gè)Zxid值，為別為：cZxid、mZxid、pZxid。

① cZxid： 是節(jié)點(diǎn)的創(chuàng)建時(shí)間所對(duì)應(yīng)的Zxid格式時(shí)間戳。

② mZxid：是節(jié)點(diǎn)的修改時(shí)間所對(duì)應(yīng)的Zxid格式時(shí)間戳。

實(shí)現(xiàn)中Zxid是一個(gè)64為的數(shù)字，它高32位是epoch用來標(biāo)識(shí)leader關(guān)系是否改變，每次一個(gè)leader被選出來，它都會(huì)有一個(gè) 新的epoch。低32位是個(gè)遞增計(jì)數(shù)。 (2) 版本號(hào)

對(duì)節(jié)點(diǎn)的每一個(gè)操作都將致使這個(gè)節(jié)點(diǎn)的版本號(hào)增加。每個(gè)節(jié)點(diǎn)維護(hù)著三個(gè)版本號(hào)，他們分別為：

① version：節(jié)點(diǎn)數(shù)據(jù)版本號(hào)

② cversion：子節(jié)點(diǎn)版本號(hào)

③ aversion：節(jié)點(diǎn)所擁有的ACL版本號(hào)

2.3 ZooKeeper節(jié)點(diǎn)屬性

通過前面的介紹，我們可以了解到，一個(gè)節(jié)點(diǎn)自身擁有表示其狀態(tài)的許多重要屬性，如下圖所示。

在ZooKeeper中有9個(gè)基本操作，如下圖所示：

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

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

盡管ZooKeeper可以被看做是一個(gè)文件系統(tǒng)，但是處于便利，摒棄了一些文件系統(tǒng)地操作原語。因?yàn)槲募浅５男〔⑶沂拐w讀寫的，所以不需要打開、關(guān)閉或是尋地的操作。

(1) watch概述

ZooKeeper可以為所有的讀操作設(shè)置watch，這些讀操作包括：exists()、getChildren()及getData()。watch事件是一次性的觸發(fā)器，當(dāng)watch的對(duì)象狀態(tài)發(fā)生改變時(shí)，將會(huì)觸發(fā)此對(duì)象上watch所對(duì)應(yīng)的事件。watch事件將被異步地發(fā)送給客戶端，并且ZooKeeper為watch機(jī)制提供了有序的一致性保證。理論上，客戶端接收watch事件的時(shí)間要快于其看到watch對(duì)象狀態(tài)變化的時(shí)間。

(2) watch類型

ZooKeeper所管理的watch可以分為兩類：

① 數(shù)據(jù)watch(data watches)：getData和exists負(fù)責(zé)設(shè)置數(shù)據(jù)watch

② 孩子watch(child watches)：getChildren負(fù)責(zé)設(shè)置孩子watch

我們可以通過操作返回的數(shù)據(jù)來設(shè)置不同的watch：

① getData和exists：返回關(guān)于節(jié)點(diǎn)的數(shù)據(jù)信息

② getChildren：返回孩子列表

因此

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

② 一個(gè)成功的create操作將觸發(fā)Znode的數(shù)據(jù)watch以及孩子watch

③ 一個(gè)成功的delete操作將觸發(fā)Znode的數(shù)據(jù)watch以及孩子watch

(3) watch注冊(cè)與處觸發(fā)

如圖下圖所示：

① exists操作上的watch，在被監(jiān)視的Znode創(chuàng)建、刪除或數(shù)據(jù)更新時(shí)被觸發(fā)。

② getData操作上的watch，在被監(jiān)視的Znode刪除或數(shù)據(jù)更新時(shí)被觸發(fā)。在被創(chuàng)建時(shí)不能被觸發(fā)，因?yàn)橹挥衂node一定存在，getData操作才會(huì)成功。

③ getChildren操作上的watch，在被監(jiān)視的Znode的子節(jié)點(diǎn)創(chuàng)建或刪除，或是這個(gè)Znode自身被刪除時(shí)被觸發(fā)。可以通過查看watch事件類型來區(qū)分是Znode，還是他的子節(jié)點(diǎn)被刪除：NodeDelete表示Znode被刪除，NodeDeletedChanged表示子節(jié)點(diǎn)被刪除。

Watch由客戶端所連接的ZooKeeper服務(wù)器在本地維護(hù)，因此watch可以非常容易地設(shè)置、管理和分派。當(dāng)客戶端連接到一個(gè)新的服務(wù)器時(shí)，任何的會(huì)話事件都將可能觸發(fā)watch。另外，當(dāng)從服務(wù)器斷開連接的時(shí)候，watch將不會(huì)被接收。但是，當(dāng)一個(gè)客戶端重新建立連接的時(shí)候，任何先前注冊(cè)過的watch都會(huì)被重新注冊(cè)。

(4) 需要注意的幾點(diǎn)

Zookeeper的watch實(shí)際上要處理兩類事件：

① 連接狀態(tài)事件(type=None, path=null)

這類事件不需要注冊(cè)，也不需要我們連續(xù)觸發(fā)，我們只要處理就行了。

② 節(jié)點(diǎn)事件

節(jié)點(diǎn)的建立，刪除，數(shù)據(jù)的修改。它是one time trigger，我們需要不停的注冊(cè)觸發(fā)，還可能發(fā)生事件丟失的情況。

上面2類事件都在Watch中處理，也就是重載的process(Event event)

節(jié)點(diǎn)事件的觸發(fā)，通過函數(shù)exists，getData或getChildren來處理這類函數(shù)，有雙重作用：

① 注冊(cè)觸發(fā)事件

② 函數(shù)本身的功能

函數(shù)的本身的功能又可以用異步的回調(diào)函數(shù)來實(shí)現(xiàn),重載processResult()過程中處理函數(shù)本身的的功能。

為了方便大家理解ZooKeeper，在此就給大家舉個(gè)例子，看看ZooKeeper是如何實(shí)現(xiàn)的他的服務(wù)的，我以ZooKeeper提供的基本服務(wù)分布式鎖為例。

5.1 分布式鎖應(yīng)用場(chǎng)景

在分布式鎖服務(wù)中，有一種最典型應(yīng)用場(chǎng)景，就是通過對(duì)集群進(jìn)行Master選舉，來解決分布式系統(tǒng)中的單點(diǎn)故障。什么是分布式系統(tǒng)中的單點(diǎn)故障：通常分布式系統(tǒng)采用主從模式，就是一個(gè)主控機(jī)連接多個(gè)處理節(jié)點(diǎn)。主節(jié)點(diǎn)負(fù)責(zé)分發(fā)任務(wù)，從節(jié)點(diǎn)負(fù)責(zé)處理任務(wù)，當(dāng)我們的主節(jié)點(diǎn)發(fā)生故障時(shí)，那么整個(gè)系統(tǒng)就都癱瘓了，那么我們把這種故障叫作單點(diǎn)故障。如下圖5.1和5.2所示：

5.2 傳統(tǒng)解決方案

傳統(tǒng)方式是采用一個(gè)備用節(jié)點(diǎn)，這個(gè)備用節(jié)點(diǎn)定期給當(dāng)前主節(jié)點(diǎn)發(fā)送ping包，主節(jié)點(diǎn)收到ping包以后向備用節(jié)點(diǎn)發(fā)送回復(fù)Ack，當(dāng)備用節(jié)點(diǎn)收到回復(fù)的時(shí)候就會(huì)認(rèn)為當(dāng)前主節(jié)點(diǎn)還活著，讓他繼續(xù)提供服務(wù)。如圖5.3所示：

當(dāng)主節(jié)點(diǎn)掛了，這時(shí)候備用節(jié)點(diǎn)收不到回復(fù)了，然后他就認(rèn)為主節(jié)點(diǎn)掛了接替他成為主節(jié)點(diǎn)如下圖5.4所示：

但是這種方式就是有一個(gè)隱患，就是網(wǎng)絡(luò)問題，來看一網(wǎng)絡(luò)問題會(huì)造成什么后果，如下圖5.5所示：

也就是說我們的主節(jié)點(diǎn)的并沒有掛，只是在回復(fù)的時(shí)候網(wǎng)絡(luò)發(fā)生故障，這樣我們的備用節(jié)點(diǎn)同樣收不到回復(fù)，就會(huì)認(rèn)為主節(jié)點(diǎn)掛了，然后備用節(jié)點(diǎn)將他的Master實(shí)例啟動(dòng)起來，這樣我們的分布式系統(tǒng)當(dāng)中就有了兩個(gè)主節(jié)點(diǎn)也就是---雙Master，出現(xiàn)Master以后我們的從節(jié)點(diǎn)就會(huì)將它所做的事一部分匯報(bào)給了主節(jié)點(diǎn)，一部分匯報(bào)給了從節(jié)點(diǎn)，這樣服務(wù)就全亂了。為了防止出現(xiàn)這種情況，我們引入了ZooKeeper，它雖然不能避免網(wǎng)絡(luò)故障，但它能夠保證每時(shí)每刻只有一個(gè)Master。我么來看一下ZooKeeper是如何實(shí)現(xiàn)的。

5.3 ZooKeeper解決方案

(1) Master啟動(dòng)

在引入了Zookeeper以后我們啟動(dòng)了兩個(gè)主節(jié)點(diǎn)，"主節(jié)點(diǎn)-A"和"主節(jié)點(diǎn)-B"他們啟動(dòng)以后，都向ZooKeeper去注冊(cè)一個(gè)節(jié)點(diǎn)。我們假設(shè)"主節(jié)點(diǎn)-A"鎖注冊(cè)地節(jié)點(diǎn)是"master-00001"，"主節(jié)點(diǎn)-B"注冊(cè)的節(jié)點(diǎn)是"master-00002"，注冊(cè)完以后進(jìn)行選舉，編號(hào)最小的節(jié)點(diǎn)將在選舉中獲勝獲得鎖成為主節(jié)點(diǎn)，也就是我們的"主節(jié)點(diǎn)-A"將會(huì)獲得鎖成為主節(jié)點(diǎn)，然后"主節(jié)點(diǎn)-B"將被阻塞成為一個(gè)備用節(jié)點(diǎn)。那么，通過這種方式就完成了對(duì)兩個(gè)Master進(jìn)程的調(diào)度。

圖5.6ZooKeeper Master選舉

(2) Master故障

如果"主節(jié)點(diǎn)-A"掛了，這時(shí)候他所注冊(cè)的節(jié)點(diǎn)將被自動(dòng)刪除，ZooKeeper會(huì)自動(dòng)感知節(jié)點(diǎn)的變化，然后再次發(fā)出選舉，這時(shí)候"主節(jié)點(diǎn)-B"將在選舉中獲勝，替代"主節(jié)點(diǎn)-A"成為主節(jié)點(diǎn)。

(3) Master 恢復(fù)

如果主節(jié)點(diǎn)恢復(fù)了，他會(huì)再次向ZooKeeper注冊(cè)一個(gè)節(jié)點(diǎn)，這時(shí)候他注冊(cè)的節(jié)點(diǎn)將會(huì)是"master-00003"，ZooKeeper會(huì)感知節(jié)點(diǎn)的變化再次發(fā)動(dòng)選舉，這時(shí)候"主節(jié)點(diǎn)-B"在選舉中會(huì)再次獲勝繼續(xù)擔(dān)任"主節(jié)點(diǎn)"，"主節(jié)點(diǎn)-A"會(huì)擔(dān)任備用節(jié)點(diǎn)。

感謝您耐心看完的文章

順便給大家推薦一個(gè)Java技術(shù)交流群：710373545里面會(huì)分享一些資深架構(gòu)師錄制的視頻資料：有Spring，MyBatis，Netty源碼分析，高并發(fā)、高性能、分布式、微服務(wù)架構(gòu)的原理，JVM性能優(yōu)化、分布式架構(gòu)等這些成為架構(gòu)師必備的知識(shí)體系。還能領(lǐng)取免費(fèi)的學(xué)習(xí)資源，目前受益良多！