[[283986]]

 ZooKeeper簡介

ZooKeeper是一個開放源碼的分布式應用程序協(xié)調(diào)服務，它包含一個簡單的原語集，分布式應用程序可以基于它實現(xiàn)同步服務，配置維護和命名服務等。

ZooKeeper設計目的

1. 最終一致性：client不論連接到哪個Server，展示給它都是同一個視圖，這是zookeeper最重要的性能。
2. 可靠性：具有簡單、健壯、良好的性能，如果消息m被到一臺服務器接受，那么它將被所有的服務器接受。
3. 實時性：Zookeeper保證客戶端將在一個時間間隔范圍內(nèi)獲得服務器的更新信息，或者服務器失效的信息。但由于網(wǎng)絡延時等原因，Zookeeper不能保證兩個客戶端能同時得到剛更新的數(shù)據(jù)，如果需要最新數(shù)據(jù)，應該在讀數(shù)據(jù)之前調(diào)用sync()接口。
4. 等待無關(wait-free)：慢的或者失效的client不得干預快速的client的請求，使得每個client都能有效的等待。
5. 原子性：更新只能成功或者失敗，沒有中間狀態(tài)。
6. 順序性：包括全局有序和偏序兩種：全局有序是指如果在一臺服務器上消息a在消息b前發(fā)布，則在所有Server上消息a都將在消息b前被發(fā)布;偏序是指如果一個消息b在消息a后被同一個發(fā)送者發(fā)布，a必將排在b前面。

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

Zookeeper會維護一個具有層次關系的數(shù)據(jù)結(jié)構(gòu)，它非常類似于一個標準的文件系統(tǒng)，如圖所示：

Zookeeper這種數(shù)據(jù)結(jié)構(gòu)有如下這些特點：

1)每個子目錄項如NameService都被稱作為znode，這個znode是被它所在的路徑唯一標識，如Server1這個znode的標識為/NameService/Server1。

2)znode可以有子節(jié)點目錄，并且每個znode可以存儲數(shù)據(jù)，注意EPHEMERAL(臨時的)類型的目錄節(jié)點不能有子節(jié)點目錄。

3)znode是有版本的(version)，每個znode中存儲的數(shù)據(jù)可以有多個版本，也就是一個訪問路徑中可以存儲多份數(shù)據(jù)，version號自動增加。

4)znode的類型：

• Persistent 節(jié)點，一旦被創(chuàng)建，便不會意外丟失，即使服務器全部重啟也依然存在。每個 Persist 節(jié)點即可包含數(shù)據(jù)，也可包含子節(jié)點。
• Ephemeral 節(jié)點，在創(chuàng)建它的客戶端與服務器間的 Session 結(jié)束時自動被刪除。服務器重啟會導致 Session 結(jié)束，因此 Ephemeral 類型的 znode 此時也會自動刪除。
• Non-sequence 節(jié)點，多個客戶端同時創(chuàng)建同一 Non-sequence 節(jié)點時，只有一個可創(chuàng)建成功，其它勻失敗。并且創(chuàng)建出的節(jié)點名稱與創(chuàng)建時指定的節(jié)點名完全一樣。
• Sequence 節(jié)點，創(chuàng)建出的節(jié)點名在指定的名稱之后帶有10位10進制數(shù)的序號。多個客戶端創(chuàng)建同一名稱的節(jié)點時，都能創(chuàng)建成功，只是序號不同。

5)znode可以被監(jiān)控，包括這個目錄節(jié)點中存儲的數(shù)據(jù)的修改，子節(jié)點目錄的變化等，一旦變化可以通知設置監(jiān)控的客戶端，這個是Zookeeper的核心特性，Zookeeper的很多功能都是基于這個特性實現(xiàn)的。

6)ZXID：每次對Zookeeper的狀態(tài)的改變都會產(chǎn)生一個zxid(ZooKeeper Transaction Id)，zxid是全局有序的，如果zxid1小于zxid2，則zxid1在zxid2之前發(fā)生。

ZooKeeper Session

Client和Zookeeper集群建立連接，整個session狀態(tài)變化如圖所示：

如果Client因為Timeout和Zookeeper Server失去連接，client處在CONNECTING狀態(tài)，會自動嘗試再去連接Server，如果在session有效期內(nèi)再次成功連接到某個Server，則回到CONNECTED狀態(tài)。

注意：如果因為網(wǎng)絡狀態(tài)不好，client和Server失去聯(lián)系，client會停留在當前狀態(tài)，會嘗試主動再次連接Zookeeper Server。client不能宣稱自己的session expired，session expired是由Zookeeper Server來決定的，client可以選擇自己主動關閉session。

ZooKeeper Watch

Zookeeper watch是一種監(jiān)聽通知機制。Zookeeper所有的讀操作getData(), getChildren()和 exists()都可以設置監(jiān)視(watch)，監(jiān)視事件可以理解為一次性的觸發(fā)器

官方定義如下：

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的三個關鍵點：

(一次性觸發(fā))One-time trigger

當設置監(jiān)視的數(shù)據(jù)發(fā)生改變時，該監(jiān)視事件會被發(fā)送到客戶端，例如，如果客戶端調(diào)用了getData("/znode1", true) 并且稍后 /znode1 節(jié)點上的數(shù)據(jù)發(fā)生了改變或者被刪除了，客戶端將會獲取到 /znode1 發(fā)生變化的監(jiān)視事件，而如果 /znode1 再一次發(fā)生了變化，除非客戶端再次對/znode1 設置監(jiān)視，否則客戶端不會收到事件通知。

(發(fā)送至客戶端)Sent to the client

Zookeeper客戶端和服務端是通過 socket 進行通信的，由于網(wǎng)絡存在故障，所以監(jiān)視事件很有可能不會成功地到達客戶端，監(jiān)視事件是異步發(fā)送至監(jiān)視者的，Zookeeper 本身提供了順序保證(ordering guarantee)：即客戶端只有首先看到了監(jiān)視事件后，才會感知到它所設置監(jiān)視的znode發(fā)生了變化(a client will never see a change for which it has set a watch until it first sees the watch event)。

網(wǎng)絡延遲或者其他因素可能導致不同的客戶端在不同的時刻感知某一監(jiān)視事件，但是不同的客戶端所看到的一切具有一致的順序。

(被設置 watch 的數(shù)據(jù))The data for which the watch was set

這意味著znode節(jié)點本身具有不同的改變方式。你也可以想象 Zookeeper 維護了兩條監(jiān)視鏈表：數(shù)據(jù)監(jiān)視和子節(jié)點監(jiān)視(data watches and child watches) getData() 和exists()設置數(shù)據(jù)監(jiān)視，getChildren()設置子節(jié)點監(jiān)視?；蛘吣阋部梢韵胂?Zookeeper 設置的不同監(jiān)視返回不同的數(shù)據(jù)，getData() 和 exists() 返回znode節(jié)點的相關信息，而getChildren() 返回子節(jié)點列表。

因此，setData() 會觸發(fā)設置在某一節(jié)點上所設置的數(shù)據(jù)監(jiān)視(假定數(shù)據(jù)設置成功)，而一次成功的create() 操作則會出發(fā)當前節(jié)點上所設置的數(shù)據(jù)監(jiān)視以及父節(jié)點的子節(jié)點監(jiān)視。一次成功的 delete操作將會觸發(fā)當前節(jié)點的數(shù)據(jù)監(jiān)視和子節(jié)點監(jiān)視事件，同時也會觸發(fā)該節(jié)點父節(jié)點的child watch。

Zookeeper 中的監(jiān)視是輕量級的，因此容易設置、維護和分發(fā)。當客戶端與 Zookeeper 服務器失去聯(lián)系時，客戶端并不會收到監(jiān)視事件的通知，只有當客戶端重新連接后，若在必要的情況下，以前注冊的監(jiān)視會重新被注冊并觸發(fā)，對于開發(fā)人員來說這通常是透明的。

只有一種情況會導致監(jiān)視事件的丟失，即：通過exists()設置了某個znode節(jié)點的監(jiān)視，但是如果某個客戶端在此znode節(jié)點被創(chuàng)建和刪除的時間間隔內(nèi)與zookeeper服務器失去了聯(lián)系，該客戶端即使稍后重新連接 zookeeper服務器后也得不到事件通知。

Consistency Guarantees

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

• 順序一致性(Sequential Consistency)：從一個客戶端來的更新請求會被順序執(zhí)行。
• 原子性(Atomicity)：更新要么成功要么失敗，沒有部分成功的情況。
• 唯一的系統(tǒng)鏡像(Single System Image)：無論客戶端連接到哪個Server，看到系統(tǒng)鏡像是一致的。
• 可靠性(Reliability)：更新一旦有效，持續(xù)有效，直到被覆蓋。
• 時間線(Timeliness)：保證在一定的時間內(nèi)各個客戶端看到的系統(tǒng)信息是一致的。

ZooKeeper的工作原理

在zookeeper的集群中，各個節(jié)點共有下面3種角色和4種狀態(tài)：

• 角色：leader,follower,observer
• 狀態(tài)：leading,following,observing,looking

Zookeeper的核心是原子廣播，這個機制保證了各個Server之間的同步。實現(xiàn)這個機制的協(xié)議叫做Zab協(xié)議(ZooKeeper Atomic Broadcast protocol)。Zab協(xié)議有兩種模式，它們分別是恢復模式(Recovery選主)和廣播模式(Broadcast同步)。

當服務啟動或者在領導者崩潰后，Zab就進入了恢復模式，當領導者被選舉出來，且大多數(shù)Server完成了和leader的狀態(tài)同步以后，恢復模式就結(jié)束了。狀態(tài)同步保證了leader和Server具有相同的系統(tǒng)狀態(tài)。

為了保證事務的順序一致性，zookeeper采用了遞增的事務id號(zxid)來標識事務。所有的提議(proposal)都在被提出的時候加上了zxid。

實現(xiàn)中zxid是一個64位的數(shù)字，它高32位是epoch用來標識leader關系是否改變，每次一個leader被選出來，它都會有一個新的epoch，標識當前屬于那個leader的統(tǒng)治時期。低32位用于遞增計數(shù)。

每個Server在工作過程中有4種狀態(tài)：

• LOOKING：當前Server不知道leader是誰，正在搜尋。
• LEADING：當前Server即為選舉出來的leader。
• FOLLOWING：leader已經(jīng)選舉出來，當前Server與之同步。
• OBSERVING：observer的行為在大多數(shù)情況下與follower完全一致，但是他們不參加選舉和投票，而僅僅接受(observing)選舉和投票的結(jié)果。

Leader Election

當leader崩潰或者leader失去大多數(shù)的follower，這時候zk進入恢復模式，恢復模式需要重新選舉出一個新的leader，讓所有的Server都恢復到一個正確的狀態(tài)。Zk的選舉算法有兩種：一種是基于basic paxos實現(xiàn)的，另外一種是基于fast paxos算法實現(xiàn)的。系統(tǒng)默認的選舉算法為fast paxos。先介紹basic paxos流程：

1. 選舉線程由當前Server發(fā)起選舉的線程擔任，其主要功能是對投票結(jié)果進行統(tǒng)計，并選出推薦的Server;
2. 選舉線程首先向所有Server發(fā)起一次詢問(包括自己);
3. 選舉線程收到回復后，驗證是否是自己發(fā)起的詢問(驗證zxid是否一致)，然后獲取對方的id(myid)，并存儲到當前詢問對象列表中，最后獲取對方提議的leader相關信息(id,zxid)，并將這些信息存儲到當次選舉的投票記錄表中;
4. 收到所有Server回復以后，就計算出zxid最大的那個Server，并將這個Server相關信息設置成下一次要投票的Server;
5. 線程將當前zxid最大的Server設置為當前Server要推薦的Leader，如果此時獲勝的Server獲得n/2 + 1的Server票數(shù)，設置當前推薦的leader為獲勝的Server，將根據(jù)獲勝的Server相關信息設置自己的狀態(tài)，否則，繼續(xù)這個過程，直到leader被選舉出來。

通過流程分析我們可以得出：要使Leader獲得多數(shù)Server的支持，則Server總數(shù)必須是奇數(shù)2n+1，且存活的Server的數(shù)目不得少于n+1.

每個Server啟動后都會重復以上流程。在恢復模式下，如果是剛從崩潰狀態(tài)恢復的或者剛啟動的server還會從磁盤快照中恢復數(shù)據(jù)和會話信息，zk會記錄事務日志并定期進行快照，方便在恢復時進行狀態(tài)恢復。

fast paxos流程是在選舉過程中，某Server首先向所有Server提議自己要成為leader，當其它Server收到提議以后，解決epoch和zxid的沖突，并接受對方的提議，然后向?qū)Ψ桨l(fā)送接受提議完成的消息，重復這個流程，最后一定能選舉出Leader。

Leader工作流程

Leader主要有三個功能：

1. 恢復數(shù)據(jù);
2. 維持與follower的心跳，接收follower請求并判斷follower的請求消息類型;
3. follower的消息類型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，根據(jù)不同的消息類型，進行不同的處理。

說明：

PING消息是指follower的心跳信息;REQUEST消息是follower發(fā)送的提議信息，包括寫請求及同步請求;

ACK消息是follower的對提議的回復，超過半數(shù)的follower通過，則commit該提議;

REVALIDATE消息是用來延長SESSION有效時間。

Follower工作流程

Follower主要有四個功能：

1. 向Leader發(fā)送請求(PING消息、REQUEST消息、ACK消息、REVALIDATE消息);
2. 接收Leader消息并進行處理;
3. 接收Client的請求，如果為寫請求，發(fā)送給Leader進行投票;
4. 返回Client結(jié)果。

Follower的消息循環(huán)處理如下幾種來自Leader的消息：

1. PING消息：心跳消息
2. PROPOSAL消息：Leader發(fā)起的提案，要求Follower投票
3. COMMIT消息：服務器端最新一次提案的信息
4. UPTODATE消息：表明同步完成
5. REVALIDATE消息：根據(jù)Leader的REVALIDATE結(jié)果，關閉待revalidate的session還是允許其接受消息
6. SYNC消息：返回SYNC結(jié)果到客戶端，這個消息最初由客戶端發(fā)起，用來強制得到最新的更新。

Zab: Broadcasting State Updates

Zookeeper Server接收到一次request，如果是follower，會轉(zhuǎn)發(fā)給leader，Leader執(zhí)行請求并通過Transaction的形式廣播這次執(zhí)行。Zookeeper集群如何決定一個Transaction是否被commit執(zhí)行?通過“兩段提交協(xié)議”(a two-phase commit)：

• Leader給所有的follower發(fā)送一個PROPOSAL消息。
• 一個follower接收到這次PROPOSAL消息，寫到磁盤，發(fā)送給leader一個ACK消息，告知已經(jīng)收到。
• 當Leader收到法定人數(shù)(quorum)的follower的ACK時候，發(fā)送commit消息執(zhí)行。

Zab協(xié)議保證：

• 如果leader以T1和T2的順序廣播，那么所有的Server必須先執(zhí)行T1，再執(zhí)行T2。
• 如果任意一個Server以T1、T2的順序commit執(zhí)行，其他所有的Server也必須以T1、T2的順序執(zhí)行。

“兩段提交協(xié)議”最大的問題是如果Leader發(fā)送了PROPOSAL消息后crash或暫時失去連接，會導致整個集群處在一種不確定的狀態(tài)(follower不知道該放棄這次提交還是執(zhí)行提交)。Zookeeper這時會選出新的leader，請求處理也會移到新的leader上，不同的leader由不同的epoch標識。切換Leader時，需要解決下面兩個問題：

1. Never forget delivered messages

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

2. Let go of messages that are skipped

Leader產(chǎn)生某個proposal，但是在crash之前，沒有follower看到這個proposal。該server恢復時，必須丟棄這個proposal。

Zookeeper會盡量保證不會同時有2個活動的Leader，因為2個不同的Leader會導致集群處在一種不一致的狀態(tài)，所以Zab協(xié)議同時保證：

• 在新的leader廣播Transaction之前，先前Leader commit的Transaction都會先執(zhí)行。
• 在任意時刻，都不會有2個Server同時有法定人數(shù)(quorum)的支持者。

這里的quorum是一半以上的Server數(shù)目，確切的說是有投票權(quán)力的Server(不包括Observer)。

總結(jié)

簡單介紹了Zookeeper的基本原理，數(shù)據(jù)模型，Session，Watch機制，一致性保證，Leader Election，Leader和Follower的工作流程和Zab協(xié)議。

參考

《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

《ZooKeeper的一致性算法賞析》https://my.oschina.net/pingpangkuangmo/blog/778927