學習 - Zookeeper

ZooKeeper 簡介：

ZooKeeper是一個分佈式的，開放源碼的分佈式應用程序協調服務，它包含一個簡單的原語集，分佈式應用程序能夠基於它實現同步服務，配置維護和命名服務等

ZooKeeper代碼版本中，提供了分佈式獨享鎖、選舉、隊列的接口，代碼在zookeeper-3.4.3\src\recipes

 

1 Zookeeper的基本概念

1.1 角色

Zookeeper中的角色主要有如下三類，以下表所示：

系統模型如圖所示：

1.2 設計目的

1. 最終一致性：client不論鏈接到哪一個Server，展現給它都是同一個視圖，這是zookeeper最重要的特性。

2. 可靠性：具備簡單、健壯、良好的性能，若是消息m被一臺服務器接受，那麼它將被全部的服務器接受。

3. 實時性：Zookeeper保證客戶端將在一個時間間隔範圍內得到服務器的更新信息，或者服務器失效的信息。但因爲網絡延時等緣由，Zookeeper不能保證兩個客戶端能同時獲得剛更新的數據，若是須要最新數據，應該在讀數據以前調用sync()接口。

4. 等待無關（wait-free）：慢的或者失效的client不得干預快速的client的請求，使得每一個client都能有效的等待。

5. 原子性：更新只能成功或者失敗，沒有中間狀態。

6. 順序性：包括全局有序和偏序兩種：全局有序是指若是在一臺服務器上消息a在消息b前發佈，則在全部Server上消息a都將在消息b前被髮布；偏序是指若是一個消息b在消息a後被同一個發送者發佈，a必將排在b前面。

2 ZooKeeper的工做原理

ZooKeeper 是以Fast Paxos算法爲基礎的，並作了一些優化，解決了活鎖（有多個交錯提交狀況時，會出現相互排斥沒法成功提交）的問題。

Zookeeper 基本運轉流程，

1. 選舉 leader

2. 同步數據

3. 選舉 leader 標準的一致性

4. leader 要有最高的 zxid（事務id號）

5. 集羣中大多數機器獲得響應並 follow 選舉出的 leader

Zookeeper 集羣是以宕機個數過半纔會讓整個集羣宕機的，因此部署奇數個節點爲佳，隨着部署節點的增長服務可靠性就越高。

 

[恢復模式和廣播模式]

Zookeeper 的核心是原子廣播，這個機制保證了各個 Server 之間的同步。實現這個機制的協議叫作 Zab 協議。Zab 協議有兩種模式，

它們分別是恢復模式（選主）和廣播模式（同步）。當服務啓動或者在領導者崩潰後，Zab 就進入了恢復模式，當領導者被選舉出來，

且大多數 Server 完成了和 leader 的狀態同步之後，恢復模式就結束了。狀態同步保證了 leader 和 Server 具備相同的系統狀態。

 

[事務順序的一致性]

爲了保證事務的順序一致性，zookeeper 採用了遞增的事務id號（zxid）來標識事務。全部的提議（proposal）都在被提出的時候加上了 zxid。

實現中 zxid 是一個64位的數字，它高32位是 epoch 用來標識leader關係是否改變，每次一個 leader 被選出來，它都會有一個新的 epoch，標識當前屬於那個 leader 的統治時期。低32位用於遞增計數。

 

[每一個Server 在工做過程當中有三種狀態]

• LOOKING：當前 Server 不知道 leader 是誰，正在搜尋

• LEADING：當前 Server 即爲選舉出來的 leader

• FOLLOWING：leader 已經選舉出來，當前 Server 與之同步

 

2.1 選主流程

當leader崩潰或者leader失去大多數的follower，這時候zk進入恢復模式，恢復模式須要從新選舉出一個新的leader，讓全部的Server都恢復到一個正確的狀態。Zk的選舉算法有兩種：一種是基於basic paxos實現的，另一種是基於fast paxos算法實現的。系統默認的選舉算法爲fast paxos。先介紹basic paxos流程：

1. 1 .選舉線程由當前Server發起選舉的線程擔任，其主要功能是對投票結果進行統計，並選出推薦的Server；

2. 2 .選舉線程首先向全部Server發起一次詢問(包括本身)；

3. 3 .選舉線程收到回覆後，驗證是不是本身發起的詢問(驗證zxid是否一致)，而後獲取對方的id(myid)，並存儲到當前詢問對象列表中，最後獲取對方提議的leader相關信息(id,zxid)，並將這些信息存儲到當次選舉的投票記錄表中；

4. 4.  收到全部Server回覆之後，就計算出zxid最大的那個Server，並將這個Server相關信息設置成下一次要投票的Server；

5. 5.  線程將當前zxid最大的Server設置爲當前Server要推薦的Leader，若是此時獲勝的Server得到n/2 + 1的Server票數， 設置當前推薦的leader爲獲勝的Server，將根據獲勝的Server相關信息設置本身的狀態，不然，繼續這個過程，直到leader被選舉出來。

經過流程分析咱們能夠得出：要使Leader得到多數Server的支持，則Server總數必須是奇數2n+1，且存活的Server的數目不得少於n+1.

每一個Server啓動後都會重複以上流程。在恢復模式下，若是是剛從崩潰狀態恢復的或者剛啓動的server還會從磁盤快照中恢復數據和會話信息，zk會記錄事務日誌並按期進行快照，方便在恢復時進行狀態恢復。選主的具體流程圖以下所示：

fast paxos流程是在選舉過程當中，某Server首先向全部Server提議本身要成爲leader，當其它Server收到提議之後，解決epoch和zxid的衝突，並接受對方的提議，而後向對方發送接受提議完成的消息，重複這個流程，最後必定能選舉出Leader。其流程圖以下所示：

2.2 同步流程

選完leader之後，zk就進入狀態同步過程。

1. 1. leader等待server鏈接；

2. 2 .Follower鏈接leader，將最大的zxid發送給leader；

3. 3 .Leader根據follower的zxid肯定同步點；

4. 4 .完成同步後通知follower 已經成爲uptodate狀態；

5. 5 .Follower收到uptodate消息後，又能夠從新接受client的請求進行服務了。

流程圖以下所示：

2.3 工做流程

2.3.1 Leader工做流程

Leader主要有三個功能：

1. 1 .恢復數據；

2. 2 .維持與Learner的心跳，接收Learner請求並判斷Learner的請求消息類型；

3. 3 .Learner的消息類型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，根據不一樣的消息類型，進行不一樣的處理。

PING消息是指Learner的心跳信息；REQUEST消息是Follower發送的提議信息，包括寫請求及同步請求；ACK消息是Follower的對提議的回覆，超過半數的Follower經過，則commit該提議；REVALIDATE消息是用來延長SESSION有效時間。
Leader的工做流程簡圖以下所示，在實際實現中，流程要比下圖複雜得多，啓動了三個線程來實現功能。

2.3.2 Follower工做流程

Follower主要有四個功能：

1. 1. 向Leader發送請求（PING消息、REQUEST消息、ACK消息、REVALIDATE消息）；

2. 2 .接收Leader消息並進行處理；

3. 3 .接收Client的請求，若是爲寫請求，發送給Leader進行投票；

4. 4 .返回Client結果。

Follower的消息循環處理以下幾種來自Leader的消息：

1. 1 .PING消息： 心跳消息；

2. 2 .PROPOSAL消息：Leader發起的提案，要求Follower投票；

3. 3 .COMMIT消息：服務器端最新一次提案的信息；

4. 4 .UPTODATE消息：代表同步完成；

5. 5 .REVALIDATE消息：根據Leader的REVALIDATE結果，關閉待revalidate的session仍是容許其接受消息；

6. 6 .SYNC消息：返回SYNC結果到客戶端，這個消息最初由客戶端發起，用來強制獲得最新的更新。

Follower的工做流程簡圖以下所示，在實際實現中，Follower是經過5個線程來實現功能的。

對於observer的流程再也不敘述，observer流程和Follower的惟一不一樣的地方就是observer不會參加leader發起的投票。

主流應用場景：

Zookeeper的主流應用場景實現思路（除去官方示例） 

(1)配置管理
集中式的配置管理在應用集羣中是很是常見的，通常商業公司內部都會實現一套集中的配置管理中心，應對不一樣的應用集羣對於共享各自配置的需求，而且在配置變動時可以通知到集羣中的每個機器。

Zookeeper很容易實現這種集中式的配置管理，好比將APP1的全部配置配置到/APP1 znode下，APP1全部機器一啓動就對/APP1這個節點進行監控(zk.exist("/APP1",true)),而且實現回調方法Watcher，那麼在zookeeper上/APP1 znode節點下數據發生變化的時候，每一個機器都會收到通知，Watcher方法將會被執行，那麼應用再取下數據便可(zk.getData("/APP1",false,null));

以上這個例子只是簡單的粗顆粒度配置監控，細顆粒度的數據能夠進行分層級監控，這一切都是能夠設計和控制的。    

 
(2)集羣管理 
應用集羣中，咱們經常須要讓每個機器知道集羣中（或依賴的其餘某一個集羣）哪些機器是活着的，而且在集羣機器由於宕機，網絡斷鏈等緣由可以不在人工介入的狀況下迅速通知到每個機器。

Zookeeper一樣很容易實現這個功能，好比我在zookeeper服務器端有一個znode叫/APP1SERVERS,那麼集羣中每個機器啓動的時候都去這個節點下建立一個EPHEMERAL類型的節點，好比server1建立/APP1SERVERS/SERVER1(可使用ip,保證不重複)，server2建立/APP1SERVERS/SERVER2，而後SERVER1和SERVER2都watch /APP1SERVERS這個父節點，那麼也就是這個父節點下數據或者子節點變化都會通知對該節點進行watch的客戶端。由於EPHEMERAL類型節點有一個很重要的特性，就是客戶端和服務器端鏈接斷掉或者session過時就會使節點消失，那麼在某一個機器掛掉或者斷鏈的時候，其對應的節點就會消失，而後集羣中全部對/APP1SERVERS進行watch的客戶端都會收到通知，而後取得最新列表便可。

另外有一個應用場景就是集羣選master,一旦master掛掉可以立刻能從slave中選出一個master,實現步驟和前者同樣，只是機器在啓動的時候在APP1SERVERS建立的節點類型變爲EPHEMERAL_SEQUENTIAL類型，這樣每一個節點會自動被編號

咱們默認規定編號最小的爲master,因此當咱們對/APP1SERVERS節點作監控的時候，獲得服務器列表，只要全部集羣機器邏輯認爲最小編號節點爲master，那麼master就被選出，而這個master宕機的時候，相應的znode會消失，而後新的服務器列表就被推送到客戶端，而後每一個節點邏輯認爲最小編號節點爲master，這樣就作到動態master選舉。

Zookeeper 監視（Watches） 簡介

Zookeeper C API 的聲明和描述在 include/zookeeper.h 中能夠找到，另外大部分的 Zookeeper C API 常量、結構體聲明也在 zookeeper.h 中，若是若是你在使用 C API 是遇到不明白的地方，最好看看 zookeeper.h，或者本身使用 doxygen 生成 Zookeeper C API 的幫助文檔。

Zookeeper 中最有特點且最不容易理解的是監視(Watches)。Zookeeper 全部的讀操做——getData(), getChildren(), 和 exists() 都 能夠設置監視(watch)，監視事件能夠理解爲一次性的觸發器， 官方定義以下： a watch event is one-time trigger, sent to the client that set the watch, which occurs when the data for which the watch was set changes。對此須要做出以下理解：

• （一次性觸發）One-time trigger

  當設置監視的數據發生改變時，該監視事件會被髮送到客戶端，例如，若是客戶端調用了 getData("/znode1", true) 而且稍後 /znode1 節點上的數據發生了改變或者被刪除了，客戶端將會獲取到 /znode1 發生變化的監視事件，而若是 /znode1 再一次發生了變化，除非客戶端再次對 /znode1 設置監視，不然客戶端不會收到事件通知。

• （發送至客戶端）Sent to the client

  Zookeeper 客戶端和服務端是經過 socket 進行通訊的，因爲網絡存在故障，因此監視事件頗有可能不會成功地到達客戶端，監視事件是異步發送至監視者的，Zookeeper 自己提供了保序性(ordering guarantee)：即客戶端只有首先看到了監視事件後，纔會感知到它所設置監視的 znode 發生了變化(a client will never see a change for which it has set a watch until it first sees the watch event). 網絡延遲或者其餘因素可能致使不一樣的客戶端在不一樣的時刻感知某一監視事件，可是不一樣的客戶端所看到的一切具備一致的順序。

• （被設置 watch 的數據）The data for which the watch was set

  這意味着 znode 節點自己具備不一樣的改變方式。你也能夠想象 Zookeeper 維護了兩條監視鏈表：數據監視和子節點監視(data watches and child watches) getData() and exists() 設置數據監視，getChildren() 設置子節點監視。 或者，你也能夠想象 Zookeeper 設置的不一樣監視返回不一樣的數據，getData() 和 exists() 返回 znode 節點的相關信息，而 getChildren() 返回子節點列表。所以， setData() 會觸發設置在某一節點上所設置的數據監視(假定數據設置成功)，而一次成功的 create() 操做則會出發當前節點上所設置的數據監視以及父節點的子節點監視。一次成功的 delete() 操做將會觸發當前節點的數據監視和子節點監視事件，同時也會觸發該節點父節點的child watch。

Zookeeper 中的監視是輕量級的，所以容易設置、維護和分發。當客戶端與 Zookeeper 服務器端失去聯繫時，客戶端並不會收到監視事件的通知，只有當客戶端從新鏈接後，若在必要的狀況下，之前註冊的監視會從新被註冊並觸發，對於開發人員來講 這一般是透明的。只有一種狀況會致使監視事件的丟失，即：經過 exists() 設置了某個 znode 節點的監視，可是若是某個客戶端在此 znode 節點被建立和刪除的時間間隔內與 zookeeper 服務器失去了聯繫，該客戶端即便稍後從新鏈接 zookeeper服務器後也得不到事件通知。

Zookeeper C API 常量與部分結構(struct)介紹

與 ACL 相關的結構與常量：

struct Id 結構爲：

struct Id {     char * scheme;     char * id; };

 

struct ACL 結構爲：

struct ACL {     int32_t perms;     struct Id id; };

 

struct ACL_vector 結構爲：

struct ACL_vector {     int32_t count;     struct ACL *data; };

 

與 znode 訪問權限有關的常量

• const int ZOO_PERM_READ; //容許客戶端讀取 znode 節點的值以及子節點列表。

• const int ZOO_PERM_WRITE;// 容許客戶端設置 znode 節點的值。

• const int ZOO_PERM_CREATE; //容許客戶端在該 znode 節點下建立子節點。

• const int ZOO_PERM_DELETE;//容許客戶端刪除子節點。

• const int ZOO_PERM_ADMIN; //容許客戶端執行 set_acl()。

• const int ZOO_PERM_ALL;//容許客戶端執行全部操做，等價與上述全部標誌的或(OR) 。

與 ACL IDs 相關的常量

• struct Id ZOO_ANYONE_ID_UNSAFE; //(‘world’,’anyone’)

• struct Id ZOO_AUTH_IDS;// (‘auth’,’’)

三種標準的 ACL

• struct ACL_vector ZOO_OPEN_ACL_UNSAFE; //(ZOO_PERM_ALL,ZOO_ANYONE_ID_UNSAFE)

• struct ACL_vector ZOO_READ_ACL_UNSAFE;// (ZOO_PERM_READ, ZOO_ANYONE_ID_UNSAFE)

• struct ACL_vector ZOO_CREATOR_ALL_ACL; //(ZOO_PERM_ALL,ZOO_AUTH_IDS)

與 Interest 相關的常量：ZOOKEEPER_WRITE, ZOOKEEPER_READ

這 兩個常量用於標識感興趣的事件並通知 zookeeper 發生了哪些事件。Interest 常量能夠進行組合或（OR）來標識多種興趣(multiple interests: write, read)，這兩個常量通常用於 zookeeper_interest() 和 zookeeper_process()兩個函數中。

與節點建立相關的常量：ZOO_EPHEMERAL, ZOO_SEQUENCE

zoo_create 函數標誌，ZOO_EPHEMERAL 用來標識建立臨時節點，ZOO_SEQUENCE 用來標識節點命名具備遞增的後綴序號(通常是節點名稱後填充 10 位字符的序號，如 /xyz0000000000, /xyz0000000001, /xyz0000000002, ...)，一樣地，ZOO_EPHEMERAL, ZOO_SEQUENCE 能夠組合。

與鏈接狀態 Stat 相關的常量

如下常量均與 Zookeeper 鏈接狀態有關，他們一般用做監視器回調函數的參數。

ZOOAPI const int	ZOO_EXPIRED_SESSION_STATE
ZOOAPI const int	ZOO_AUTH_FAILED_STATE
ZOOAPI const int	ZOO_CONNECTING_STATE
ZOOAPI const int	ZOO_ASSOCIATING_STATE
ZOOAPI const int	ZOO_CONNECTED_STATE

與監視類型(Watch Types)相關的常量

如下常量標識監視事件的類型，他們一般用做監視器回調函數的第一個參數。

• ZOO_CREATED_EVENT; // 節點被建立(此前該節點不存在)，經過 zoo_exists() 設置監視。

• ZOO_DELETED_EVENT; // 節點被刪除，經過 zoo_exists() 和 zoo_get() 設置監視。

• ZOO_CHANGED_EVENT; // 節點發生變化，經過 zoo_exists() 和 zoo_get() 設置監視。

• ZOO_CHILD_EVENT; // 子節點事件，經過zoo_get_children() 和 zoo_get_children2()設置監視。

• ZOO_SESSION_EVENT; // 會話丟失

• ZOO_NOTWATCHING_EVENT; // 監視被移除。

Zookeeper C API 錯誤碼介紹 ZOO_ERRORS

ZOK	正常返回
ZSYSTEMERROR	系統或服務器端錯誤(System and server-side errors)，服務器不會拋出該錯誤，該錯誤也只是用來標識錯誤範圍的，即大於該錯誤值，且小於 ZAPIERROR 都是系統錯誤。
ZRUNTIMEINCONSISTENCY	運行時非一致性錯誤。
ZDATAINCONSISTENCY	數據非一致性錯誤。
ZCONNECTIONLOSS	Zookeeper 客戶端與服務器端失去鏈接
ZMARSHALLINGERROR	在 marshalling 和 unmarshalling 數據時出現錯誤(Error while marshalling or unmarshalling data)
ZUNIMPLEMENTED	該操做未實現(Operation is unimplemented)
ZOPERATIONTIMEOUT	該操做超時(Operation timeout)
ZBADARGUMENTS	非法參數錯誤(Invalid arguments)
ZINVALIDSTATE	非法句柄狀態(Invliad zhandle state)
ZAPIERROR	API 錯誤(API errors)，服務器不會拋出該錯誤，該錯誤也只是用來標識錯誤範圍的，錯誤值大於該值的標識 API 錯誤，而小於該值的標識 ZSYSTEMERROR。
ZNONODE	節點不存在(Node does not exist)
ZNOAUTH	沒有通過受權(Not authenticated)
ZBADVERSION	版本衝突(Version conflict)
ZNOCHILDRENFOREPHEMERALS	臨時節點不能擁有子節點(Ephemeral nodes may not have children)
ZNODEEXISTS	節點已經存在(The node already exists)
ZNOTEMPTY	該節點具備自身的子節點(The node has children)
ZSESSIONEXPIRED	會話過時(The session has been expired by the server)
ZINVALIDCALLBACK	非法的回調函數(Invalid callback specified)
ZINVALIDACL	非法的ACL(Invalid ACL specified)
ZAUTHFAILED	客戶端受權失敗(Client authentication failed)
ZCLOSING	Zookeeper 鏈接關閉(ZooKeeper is closing)
ZNOTHING	並不是錯誤，客戶端不須要處理服務器的響應(not error, no server responses to process)
ZSESSIONMOVED	會話轉移至其餘服務器，因此操做被忽略(session moved to another server, so operation is ignored)

 

Watch事件類型：

 

ZOO_CREATED_EVENT：節點建立事件，須要watch一個不存在的節點，當節點被建立時觸發，此watch經過zoo_exists()設置ZOO_DELETED_EVENT：節點刪除事件，此watch經過zoo_exists()或zoo_get()設置ZOO_CHANGED_EVENT：節點數據改變事件，此watch經過zoo_exists()或zoo_get()設置ZOO_CHILD_EVENT：子節點列表改變事件，此watch經過zoo_get_children()或zoo_get_children2()設置ZOO_SESSION_EVENT：會話失效事件，客戶端與服務端斷開或重連時觸發ZOO_NOTWATCHING_EVENT：watch移除事件，服務端出於某些緣由再也不爲客戶端watch節點時觸發