Zookeeper--起步

前言

        在平常工做中，zk的應用場景是很是多，好比rpc中掛載服務，分佈式鎖、配置維護、組服務、分佈式消息隊列、分佈式通知/協調等等，zk設計之初是模仿google的chubby，提供分佈式協調服務（實分佈式協調技術主要用來解決分佈式環境當中多個進程之間的同步控制），因此分佈式鎖功能是zk的基本功能。

ZK介紹

    zk性能上的特色決定了它可以用在大型的、分佈式的系統當中。從可靠性方面來講，它並不會由於一個節點的錯誤而崩潰。除此以外，它嚴格的序列訪問控制意味着複雜的控制原語能夠應用在客戶端上。zk在一致性、可用性、容錯性的保證，也是zk的成功之處，它得到的一切成功都與它採用的協議——Zab協議是密不可分的。

    zk採用了一套叫作Znode的數據結構，而後在該數據結構的基礎上定義了一些原語，也就是一些關於該數據結構的一些操做。有了這些數據結構和原語還不夠，由於咱們的ZooKeeper是工做在一個分佈式的環境下，咱們的服務是經過消息以網絡的形式發送給咱們的分佈式應用程序，因此還須要一個通知機制——Watcher機制。那麼總結一下，ZooKeeper所提供的服務主要是經過：數據結構+原語+watcher機制，三個部分來實現的。

    znode的結構和unix系統的目錄結構很是類似，但有不徹底相同，znode結構主要有一下特色：

 引用方式

    Zonde經過路徑引用，如同Unix中的文件路徑。路徑必須是絕對的，所以他們必須由斜槓字符來開頭。除此之外，他們必須是惟一的，也就是說每個路徑只有一個表示，所以這些路徑不能改變。在zk中，路徑由Unicode字符串組成，而且有一些限制。字符串"/zookeeper"用以保存管理信息，好比關鍵配額信息。

Znode結構

    zk命名空間中的Znode，兼具文件和目錄兩種特色。既像文件同樣維護着數據、元信息、ACL、時間戳等數據結構，又像目錄同樣能夠做爲路徑標識的一部分。圖中的每一個節點稱爲一個Znode。 每一個Znode由3部分組成:

① stat：此爲狀態信息, 描述該Znode的版本, 權限等信息

② data：與該Znode關聯的數據

③ children：該Znode下的子節點

    zk雖然能夠關聯一些數據，但並無被設計爲常規的數據庫或者大數據存儲，相反的是，它用來管理調度數據，好比分佈式應用中的配置文件信息、狀態信息、聚集位置等等。這些數據的共同特性就是它們都是很小的數據，一般以KB爲大小單位。ZooKeeper的服務器和客戶端都被設計爲嚴格檢查並限制每一個Znode的數據大小至多1M，但常規使用中應該遠小於此值。

數據訪問

    zk中的每一個節點存儲的數據要被原子性的操做。也就是說讀操做將獲取與節點相關的全部數據，寫操做也將替換掉節點的全部數據。另外，每個節點都擁有本身的ACL(訪問控制列表)，這個列表規定了用戶的權限，即限定了特定用戶對目標節點能夠執行的操做。

節點類型

    zk中的節點有兩種，分別爲臨時節點和永久節點。節點的類型在建立時即被肯定，而且不能改變。

     臨時節點：該節點的生命週期依賴於建立它們的會話。一旦會話(Session)結束，臨時節點將被自動刪除，固然能夠也能夠手動刪除。雖然每一個臨時的Znode都會綁定到一個客戶端會話，但他們對全部的客戶端仍是可見的。另外，zk的臨時節點不容許擁有子節點。

    永久節點：該節點的生命週期不依賴於會話，而且只有在客戶端顯示執行刪除操做的時候，他們才能被刪除。

順序節點

    當建立Znode的時候，用戶能夠請求在zk的路徑結尾添加一個遞增的計數。這個計數對於此節點的父節點來講是惟一的，它的格式爲"%10d"(10位數字，沒有數值的數位用0補充，例如"0000000001")。當計數值大於232-1時，計數器將溢出。

 觀察

    客戶端能夠在節點上設置watch，咱們稱之爲監視器。當節點狀態發生改變時(Znode的增、刪、改)將會觸發watch所對應的操做。當watch被觸發時，zk將會向客戶端發送且僅發送一條通知，由於watch只能被觸發一次，這樣能夠減小網絡流量。

 

zk節點相關

zk有多種記錄時間的形式，其中包含如下幾個主要屬性：

(1) Zxid

導致ZooKeeper節點狀態改變的每個操做都將使節點接收到一個Zxid格式的時間戳，而且這個時間戳全局有序。也就是說，也就是說，每一個對節點的改變都將產生一個惟一的Zxid。若是Zxid1的值小於Zxid2的值，那麼Zxid1所對應的事件發生在Zxid2所對應的事件以前。實際上，ZooKeeper的每一個節點維護者三個Zxid值，爲別爲：cZxid、mZxid、pZxid。

① cZxid： 是節點的建立時間所對應的Zxid格式時間戳。
② mZxid：是節點的修改時間所對應的Zxid格式時間戳。

實現中Zxid是一個64爲的數字，它高32位是epoch用來標識leader關係是否改變，每次一個leader被選出來，它都會有一個 新的epoch。低32位是個遞增計數。 (2) 版本號

對節點的每個操做都將導致這個節點的版本號增長。每一個節點維護着三個版本號，他們分別爲：

① version：節點數據版本號
② cversion：子節點版本號
③ aversion：節點所擁有的ACL版本號

對節點的操做包括如下：

    更新ZooKeeper操做是有限制的。delete或setData必須明確要更新的Znode的版本號，咱們能夠調用exists找到。若是版本號不匹配，更新將會失敗。

    更新ZooKeeper操做是非阻塞式的。所以客戶端若是失去了一個更新(因爲另外一個進程在同時更新這個Znode)，他能夠在不阻塞其餘進程執行的狀況下，選擇從新嘗試或進行其餘操做。

    儘管ZooKeeper能夠被看作是一個文件系統，可是處於便利，摒棄了一些文件系統地操做原語。由於文件很是的小而且使總體讀寫的，因此不須要打開、關閉或是尋地的操做。

1) watch概述

ZooKeeper能夠爲全部的讀操做設置watch，這些讀操做包括：exists()、getChildren()及getData()。watch事件是一次性的觸發器，當watch的對象狀態發生改變時，將會觸發此對象上watch所對應的事件。watch事件將被異步地發送給客戶端，而且ZooKeeper爲watch機制提供了有序的一致性保證。理論上，客戶端接收watch事件的時間要快於其看到watch對象狀態變化的時間。

(2) watch類型

ZooKeeper所管理的watch能夠分爲兩類：

① 數據watch(data  watches)：getData和exists負責設置數據watch
② 孩子watch(child watches)：getChildren負責設置孩子watch

咱們能夠經過操做返回的數據來設置不一樣的watch：

① getData和exists：返回關於節點的數據信息
② getChildren：返回孩子列表

所以

① 一個成功的setData操做將觸發Znode的數據watch

② 一個成功的create操做將觸發Znode的數據watch以及孩子watch

③ 一個成功的delete操做將觸發Znode的數據watch以及孩子watch

(3) watch註冊與處觸發

圖 6.1 watch設置操做及相應的觸發器如圖下圖所示：

① exists操做上的watch，在被監視的Znode建立、刪除或數據更新時被觸發。
② getData操做上的watch，在被監視的Znode刪除或數據更新時被觸發。在被建立時不能被觸發，由於只有Znode必定存在，getData操做纔會成功。
③ getChildren操做上的watch，在被監視的Znode的子節點建立或刪除，或是這個Znode自身被刪除時被觸發。能夠經過查看watch事件類型來區分是Znode，仍是他的子節點被刪除：NodeDelete表示Znode被刪除，NodeDeletedChanged表示子節點被刪除。

　　Watch由客戶端所鏈接的ZooKeeper服務器在本地維護，所以watch能夠很是容易地設置、管理和分派。當客戶端鏈接到一個新的服務器時，任何的會話事件都將可能觸發watch。另外，當從服務器斷開鏈接的時候，watch將不會被接收。可是，當一個客戶端從新創建鏈接的時候，任何先前註冊過的watch都會被從新註冊。

 

(4) 須要注意的幾點

Zookeeper的watch實際上要處理兩類事件：

① 鏈接狀態事件(type=None, path=null)

這類事件不須要註冊，也不須要咱們連續觸發，咱們只要處理就好了。

② 節點事件

節點的創建，刪除，數據的修改。它是one time trigger，咱們須要不停的註冊觸發，還可能發生事件丟失的狀況。

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

節點事件的觸發，經過函數exists，getData或getChildren來處理這類函數，有雙重做用：

① 註冊觸發事件

② 函數自己的功能

函數的自己的功能又能夠用異步的回調函數來實現,重載processResult()過程當中處理函數自己的的功能。

總結

    zk的設計巧妙之處在於對zab和znode的結構設計上，本篇博文經過前人概括總結的zk在znode設計上的巧思，讓咱們後來人對zk一開始就有比較高的高度去起步學習，對zk的api使用上能很是輕易的上手。