ZooKeeper基本原理

ZooKeeper簡介

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

 

ZooKeeper設計目的

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前面。

ZooKeeper數據模型

Zookeeper會維護一個具備層次關係的數據結構，它很是相似於一個標準的文件系統，如圖所示：

Zookeeper這種數據結構有以下這些特色：

1）每一個子目錄項如NameService都被稱做爲znode，這個znode是被它所在的路徑惟一標識，如Server1這個znode的標識爲/NameService/Server1。

2）znode能夠有子節點目錄，而且每一個znode能夠存儲數據，注意EPHEMERAL（臨時的）類型的目錄節點不能有子節點目錄。

3）znode是有版本的（version），每一個znode中存儲的數據能夠有多個版本，也就是一個訪問路徑中能夠存儲多份數據，version號自動增長。

4）znode能夠是臨時節點（EPHEMERAL），能夠是持久節點（PERSISTENT）。若是建立的是臨時節點，一旦建立這個EPHEMERALznode的客戶端與服務器失去聯繫，這個znode也將自動刪除，Zookeeper的客戶端和服務器通訊採用長鏈接方式，每一個客戶端和服務器經過心跳來保持鏈接，這個鏈接狀態稱爲session，若是znode是臨時節點，這個session失效，znode也就刪除了。

5）znode的目錄名能夠自動編號，如App1已經存在，再建立的話，將會自動命名爲App2。

6）znode能夠被監控，包括這個目錄節點中存儲的數據的修改，子節點目錄的變化等，一旦變化能夠通知設置監控的客戶端，這個是Zookeeper的核心特性，Zookeeper的不少功能都是基於這個特性實現的。

7）ZXID：每次對Zookeeper的狀態的改變都會產生一個zxid（ZooKeeper Transaction Id），zxid是全局有序的，若是zxid1小於zxid2，則zxid1在zxid2以前發生。

ZooKeeper Session

Client和Zookeeper集羣創建鏈接，整個session狀態變化如圖所示：

若是Client由於Timeout和Zookeeper Server失去鏈接，client處在CONNECTING狀態，會自動嘗試再去鏈接Server，若是在session有效期內再次成功鏈接到某個Server，則回到CONNECTED狀態。

注意：若是由於網絡狀態很差，client和Server失去聯繫，client會停留在當前狀態，會嘗試主動再次鏈接Zookeeper Server。client不能宣稱本身的session expired，session expired是由Zookeeper Server來決定的，client能夠選擇本身主動關閉session。

ZooKeeper Watch

Zookeeper watch是一種監聽通知機制。Zookeeper全部的讀操做getData(), getChildren()和 exists()均可以設置監視(watch)，監視事件能夠理解爲一次性的觸發器，官方定義以下： a watch event is one-time trigger, sent to the client that set the watch, whichoccurs when the data for which the watch was set changes。Watch的三個關鍵點：

*（一次性觸發）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() 和exists()設置數據監視，getChildren()設置子節點監視。或者你也能夠想象 Zookeeper 設置的不一樣監視返回不一樣的數據，getData() 和 exists() 返回znode節點的相關信息，而getChildren() 返回子節點列表。所以，setData() 會觸發設置在某一節點上所設置的數據監視（假定數據設置成功），而一次成功的create() 操做則會出發當前節點上所設置的數據監視以及父節點的子節點監視。一次成功的 delete操做將會觸發當前節點的數據監視和子節點監視事件，同時也會觸發該節點父節點的child watch。

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

Consistency Guarantees

Zookeeper是一個高效的、可擴展的服務，read和write操做都被設計爲快速的，read比write操做更快。

順序一致性（Sequential Consistency）：從一個客戶端來的更新請求會被順序執行。

原子性（Atomicity）：更新要麼成功要麼失敗，沒有部分紅功的狀況。

惟一的系統鏡像（Single System Image）：不管客戶端鏈接到哪一個Server，看到系統鏡像是一致的。

可靠性（Reliability）：更新一旦有效，持續有效，直到被覆蓋。

時間線（Timeliness）：保證在必定的時間內各個客戶端看到的系統信息是一致的。

ZooKeeper的工做原理

在zookeeper的集羣中，各個節點共有下面3種角色和4種狀態：

• 角色：leader,follower,observer
• 狀態：leading,following,observing,looking

Zookeeper的核心是原子廣播，這個機制保證了各個Server之間的同步。實現這個機制的協議叫作Zab協議（ZooKeeper Atomic Broadcast protocol）。Zab協議有兩種模式，它們分別是恢復模式（Recovery選主）和廣播模式（Broadcast同步）。當服務啓動或者在領導者崩潰後，Zab就進入了恢復模式，當領導者被選舉出來，且大多數Server完成了和leader的狀態同步之後，恢復模式就結束了。狀態同步保證了leader和Server具備相同的系統狀態。

爲了保證事務的順序一致性，zookeeper採用了遞增的事務id號（zxid）來標識事務。全部的提議（proposal）都在被提出的時候加上了zxid。實現中zxid是一個64位的數字，它高32位是epoch用來標識leader關係是否改變，每次一個leader被選出來，它都會有一個新的epoch，標識當前屬於那個leader的統治時期。低32位用於遞增計數。

每一個Server在工做過程當中有4種狀態：

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

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

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

OBSERVING：observer的行爲在大多數狀況下與follower徹底一致，可是他們不參加選舉和投票，而僅僅接受(observing)選舉和投票的結果。

Leader Election

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

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

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

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

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

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。

Leader工做流程

Leader主要有三個功能：

1.恢復數據；

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

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

PING消息是指Learner的心跳信息；REQUEST消息是Follower發送的提議信息，包括寫請求及同步請求；

ACK消息是Follower的對提議的回覆，超過半數的Follower經過，則commit該提議；REVALIDATE消息是用來延長SESSION有效時間。

Follower工做流程

Follower主要有四個功能：

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

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

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

4.返回Client結果。

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

1.PING消息：心跳消息

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

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

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

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

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

Zab: Broadcasting State Updates

Zookeeper Server接收到一次request，若是是follower，會轉發給leader，Leader執行請求並經過Transaction的形式廣播此次執行。Zookeeper集羣如何決定一個Transaction是否被commit執行？經過「兩段提交協議」（a two-phase commit）：

1. Leader給全部的follower發送一個PROPOSAL消息。
2. 一個follower接收到此次PROPOSAL消息，寫到磁盤，發送給leader一個ACK消息，告知已經收到。
3. 當Leader收到法定人數（quorum）的follower的ACK時候，發送commit消息執行。

Zab協議保證：

• 1）  若是leader以T1和T2的順序廣播，那麼全部的Server必須先執行T1，再執行T2。
• 2）  若是任意一個Server以T一、T2的順序commit執行，其餘全部的Server也必須以T一、T2的順序執行。

「兩段提交協議」最大的問題是若是Leader發送了PROPOSAL消息後crash或暫時失去鏈接，會致使整個集羣處在一種不肯定的狀態（follower不知道該放棄此次提交仍是執行提交）。Zookeeper這時會選出新的leader，請求處理也會移到新的leader上，不一樣的leader由不一樣的epoch標識。切換Leader時，須要解決下面兩個問題：

Never forget delivered messages

Leader在COMMIT投遞到任何一臺follower以前crash，只有它本身commit了。新Leader必須保證這個事務也必須commit。

Let go of messages that are skipped

Leader產生某個proposal，可是在crash以前，沒有follower看到這個proposal。該server恢復時，必須丟棄這個proposal。

Zookeeper會盡可能保證不會同時有2個活動的Leader，由於2個不一樣的Leader會致使集羣處在一種不一致的狀態，因此Zab協議同時保證：

• 1）  在新的leader廣播Transaction以前，先前Leader commit的Transaction都會先執行。
• 2）  在任意時刻，都不會有2個Server同時有法定人數（quorum）的支持者。

這裏的quorum是一半以上的Server數目，確切的說是有投票權力的Server（不包括Observer）。

 

總結：簡單介紹了Zookeeper的基本原理，數據模型，Session，Watch機制，一致性保證，Leader Election，Leader和Follower的工做流程和Zab協議。

 

參考：

《ZooKeeper—Distributed Process Coordination》 by FlavioJunqueira and Benjamin Reed

http://zookeeper.apache.org/doc/trunk/zookeeperOver.html

http://www.ibm.com/developerworks/cn/opensource/os-cn-zookeeper/index.html