ZooKeeper 簡(jiǎn)介
ZooKeeper是一個(gè)開放源碼的分布式應(yīng)用程序協(xié)調(diào)服務(wù)，它包含一個(gè)簡(jiǎn)單的原語(yǔ)集，分布式應(yīng)用程序可以基于它實(shí)現(xiàn)同步服務(wù)，配置維護(hù)和命名服務(wù)等。
ZooKeeper 設(shè)計(jì)目的
1.最終一致性：client不論連接到哪個(gè)Server，展示給它都是同一個(gè)視圖，這是zookeeper最重要的性能。
2.可靠性：具有簡(jiǎn)單、健壯、良好的性能，如果消息m被到一臺(tái)服務(wù)器接受，那么它將被所有的服務(wù)器接受。
3.實(shí)時(shí)性：Zookeeper保證客戶端將在一個(gè)時(shí)間間隔范圍內(nèi)獲得服務(wù)器的更新信息，或者服務(wù)器失效的信息。
但由于網(wǎng)絡(luò)延時(shí)等原因，Zookeeper不能保證兩個(gè)客戶端能同時(shí)得到剛更新的數(shù)據(jù)，如果需要最新數(shù)據(jù)，應(yīng)該在讀數(shù)據(jù)之前調(diào)用sync()接口。
4.等待無(wú)關(guān)（wait-free）：慢的或者失效的client不得干預(yù)快速的client的請(qǐng)求，使得每個(gè)client都能有效的等待。
5.原子性：更新只能成功或者失敗，沒有中間狀態(tài)。
6.順序性：包括全局有序和偏序兩種：全局有序是指如果在一臺(tái)服務(wù)器上消息a在消息b前發(fā)布，則在所有Server上消息a都將在消息b前被發(fā)布；偏序是指如果一個(gè)消息b在消息a后被同一個(gè)發(fā)送者發(fā)布，a必將排在b前面。
ZooKeeper數(shù)據(jù)模型
Zookeeper會(huì)維護(hù)一個(gè)具有層次關(guān)系的數(shù)據(jù)結(jié)構(gòu)，它非常類似于一個(gè)標(biāo)準(zhǔn)的文件系統(tǒng)，如圖所示：
Zookeeper這種數(shù)據(jù)結(jié)構(gòu)有如下這些特點(diǎn)：
1）每個(gè)子目錄項(xiàng)如NameService都被稱作為znode，這個(gè)znode是被它所在的路徑唯一標(biāo)識(shí)，如Server1這個(gè)znode的標(biāo)識(shí)為/NameService/Server1。
2）znode可以有子節(jié)點(diǎn)目錄，并且每個(gè)znode可以存儲(chǔ)數(shù)據(jù)，注意EPHEMERAL（臨時(shí)的）類型的目錄節(jié)點(diǎn)不能有子節(jié)點(diǎn)目錄。
3）znode是有版本的（version），每個(gè)znode中存儲(chǔ)的數(shù)據(jù)可以有多個(gè)版本，也就是一個(gè)訪問路徑中可以存儲(chǔ)多份數(shù)據(jù)，version號(hào)自動(dòng)增加。
4）znode的類型：
? Persistent 節(jié)點(diǎn)，一旦被創(chuàng)建，便不會(huì)意外丟失，即使服務(wù)器全部重啟也依然存在。每個(gè) Persist 節(jié)點(diǎn)即可包含數(shù)據(jù)，也可包含子節(jié)點(diǎn)。
? Ephemeral 節(jié)點(diǎn)，在創(chuàng)建它的客戶端與服務(wù)器間的 Session 結(jié)束時(shí)自動(dòng)被刪除。服務(wù)器重啟會(huì)導(dǎo)致 Session 結(jié)束，因此 Ephemeral 類型的 znode 此時(shí)也會(huì)自動(dòng)刪除。
? Non-sequence 節(jié)點(diǎn)，多個(gè)客戶端同時(shí)創(chuàng)建同一 Non-sequence 節(jié)點(diǎn)時(shí)，只有一個(gè)可創(chuàng)建成功，其它勻失敗。并且創(chuàng)建出的節(jié)點(diǎn)名稱與創(chuàng)建時(shí)指定的節(jié)點(diǎn)名完全一樣。
? Sequence 節(jié)點(diǎn)，創(chuàng)建出的節(jié)點(diǎn)名在指定的名稱之后帶有10位10進(jìn)制數(shù)的序號(hào)。多個(gè)客戶端創(chuàng)建同一名稱的節(jié)點(diǎn)時(shí)，都能創(chuàng)建成功，只是序號(hào)不同。
5）znode可以被監(jiān)控，包括這個(gè)目錄節(jié)點(diǎn)中存儲(chǔ)的數(shù)據(jù)的修改，子節(jié)點(diǎn)目錄的變化等，一旦變化可以通知設(shè)置監(jiān)控的客戶端，這個(gè)是Zookeeper的核心特性，Zookeeper的很多功能都是基于這個(gè)特性實(shí)現(xiàn)的。
6）ZXID：每次對(duì)Zookeeper的狀態(tài)的改變都會(huì)產(chǎn)生一個(gè)zxid（ZooKeeper Transaction Id），zxid是全局有序的，如果zxid1小于zxid2，則zxid1在zxid2之前發(fā)生。
ZooKeeper Session
Client和Zookeeper集群建立連接，整個(gè)session狀態(tài)變化如圖所示：
如果Client因?yàn)門imeout和Zookeeper Server失去連接，client處在CONNECTING狀態(tài)，會(huì)自動(dòng)嘗試再去連接Server，如果在session有效期內(nèi)再次成功連接到某個(gè)Server，則回到CONNECTED狀態(tài)。
注意：如果因?yàn)榫W(wǎng)絡(luò)狀態(tài)不好，client和Server失去聯(lián)系，client會(huì)停留在當(dāng)前狀態(tài)，會(huì)嘗試主動(dòng)再次連接Zookeeper Server。client不能宣稱自己的session expired，session expired是由Zookeeper Server來(lái)決定的，client可以選擇自己主動(dòng)關(guān)閉session。
ZooKeeper Watch
Zookeeper watch是一種監(jiān)聽通知機(jī)制。Zookeeper所有的讀操作getData(), getChildren()和 exists()都可以設(shè)置監(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的三個(gè)關(guān)鍵點(diǎn)：
? （一次性觸發(fā)）One-time trigger
當(dāng)設(shè)置監(jiān)視的數(shù)據(jù)發(fā)生改變時(shí)，該監(jiān)視事件會(huì)被發(fā)送到客戶端。
例如，如果客戶端調(diào)用了getData(/znode1, true) 并且稍后 /znode1 節(jié)點(diǎn)上的數(shù)據(jù)發(fā)生了改變或者被刪除了，客戶端將會(huì)獲取到 /znode1 發(fā)生變化的監(jiān)視事件；
而如果 /znode1 再一次發(fā)生了變化，除非客戶端再次對(duì)/znode1 設(shè)置監(jiān)視，否則客戶端不會(huì)收到事件通知。
? （發(fā)送至客戶端）Sent to the client
Zookeeper客戶端和服務(wù)端是通過(guò) socket 進(jìn)行通信的，由于網(wǎng)絡(luò)存在故障，所以監(jiān)視事件很有可能不會(huì)成功地到達(dá)客戶端，監(jiān)視事件是異步發(fā)送至監(jiān)視者的。
Zookeeper 本身提供了順序保證(ordering guarantee)：即客戶端只有首先看到了監(jiān)視事件后，才會(huì)感知到它所設(shè)置監(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)絡(luò)延遲或者其他因素可能導(dǎo)致不同的客戶端在不同的時(shí)刻感知某一監(jiān)視事件，但是不同的客戶端所看到的一切具有一致的順序。
? （被設(shè)置 watch 的數(shù)據(jù)）The data for which the watch was set
這意味著znode節(jié)點(diǎn)本身具有不同的改變方式。你也可以想象 Zookeeper 維護(hù)了兩條監(jiān)視鏈表：數(shù)據(jù)監(jiān)視和子節(jié)點(diǎn)監(jiān)視(data watches and child watches) getData() 和exists()設(shè)置數(shù)據(jù)監(jiān)視，getChildren()設(shè)置子節(jié)點(diǎn)監(jiān)視。
或者你也可以想象 Zookeeper 設(shè)置的不同監(jiān)視返回不同的數(shù)據(jù)，getData() 和 exists() 返回znode節(jié)點(diǎn)的相關(guān)信息，而getChildren() 返回子節(jié)點(diǎn)列表。
因此，setData() 會(huì)觸發(fā)設(shè)置在某一節(jié)點(diǎn)上所設(shè)置的數(shù)據(jù)監(jiān)視（假定數(shù)據(jù)設(shè)置成功），而一次成功的create() 操作則會(huì)出發(fā)當(dāng)前節(jié)點(diǎn)上所設(shè)置的數(shù)據(jù)監(jiān)視以及父節(jié)點(diǎn)的子節(jié)點(diǎn)監(jiān)視。
一次成功的 delete操作將會(huì)觸發(fā)當(dāng)前節(jié)點(diǎn)的數(shù)據(jù)監(jiān)視和子節(jié)點(diǎn)監(jiān)視事件，同時(shí)也會(huì)觸發(fā)該節(jié)點(diǎn)父節(jié)點(diǎn)的child watch。
Zookeeper 中的監(jiān)視是輕量級(jí)的，因此容易設(shè)置、維護(hù)和分發(fā)。當(dāng)客戶端與 Zookeeper 服務(wù)器失去聯(lián)系時(shí)，客戶端并不會(huì)收到監(jiān)視事件的通知，只有當(dāng)客戶端重新連接后，若在必要的情況下，以前注冊(cè)的監(jiān)視會(huì)重新被注冊(cè)并觸發(fā)，對(duì)于開發(fā)人員來(lái)說(shuō)這通常是透明的。
只有一種情況會(huì)導(dǎo)致監(jiān)視事件的丟失，即：通過(guò)exists()設(shè)置了某個(gè)znode節(jié)點(diǎn)的監(jiān)視，但是如果某個(gè)客戶端在此znode節(jié)點(diǎn)被創(chuàng)建和刪除的時(shí)間間隔內(nèi)與zookeeper服務(wù)器失去了聯(lián)系，該客戶端即使稍后重新連接 zookeeper服務(wù)器后也得不到事件通知。
Consistency Guarantees
Zookeeper是一個(gè)高效的、可擴(kuò)展的服務(wù)，read和write操作都被設(shè)計(jì)為快速的，read比write操作更快。
? 順序一致性（Sequential Consistency）：從一個(gè)客戶端來(lái)的更新請(qǐng)求會(huì)被順序執(zhí)行。
? 原子性（Atomicity）：更新要么成功要么失敗，沒有部分成功的情況。
? 唯一的系統(tǒng)鏡像（Single System Image）：無(wú)論客戶端連接到哪個(gè)Server，看到系統(tǒng)鏡像是一致的。
? 可靠性（Reliability）：更新一旦有效，持續(xù)有效，直到被覆蓋。
? 時(shí)間線（Timeliness）：保證在一定的時(shí)間內(nèi)各個(gè)客戶端看到的系統(tǒng)信息是一致的。
ZooKeeper的工作原理
在zookeeper的集群中，各個(gè)節(jié)點(diǎn)共有下面3種角色和4種狀態(tài)：
? 角色：leader,follower,observer
? 狀態(tài)：leading,following,observing,looking
Zookeeper的核心是原子廣播，這個(gè)機(jī)制保證了各個(gè)Server之間的同步。實(shí)現(xiàn)這個(gè)機(jī)制的協(xié)議叫做Zab協(xié)議（ZooKeeper Atomic Broadcast protocol）。Zab協(xié)議有兩種模式，它們分別是恢復(fù)模式（Recovery選主）和廣播模式（Broadcast同步）。
當(dāng)服務(wù)啟動(dòng)或者在領(lǐng)導(dǎo)者崩潰后，Zab就進(jìn)入了恢復(fù)模式，當(dāng)領(lǐng)導(dǎo)者被選舉出來(lái)，且大多數(shù)Server完成了和leader的狀態(tài)同步以后，恢復(fù)模式就結(jié)束了。狀態(tài)同步保證了leader和Server具有相同的系統(tǒng)狀態(tài)。
為了保證事務(wù)的順序一致性，zookeeper采用了遞增的事務(wù)id號(hào)（zxid）來(lái)標(biāo)識(shí)事務(wù)。所有的提議（proposal）都在被提出的時(shí)候加上了zxid。
實(shí)現(xiàn)中zxid是一個(gè)64位的數(shù)字，它高32位是epoch用來(lái)標(biāo)識(shí)leader關(guān)系是否改變，每次一個(gè)leader被選出來(lái)，它都會(huì)有一個(gè)新的epoch，標(biāo)識(shí)當(dāng)前屬于那個(gè)leader的統(tǒng)治時(shí)期。低32位用于遞增計(jì)數(shù)。
每個(gè)Server在工作過(guò)程中有4種狀態(tài)：
? LOOKING：當(dāng)前Server不知道leader是誰(shuí)，正在搜尋。
? LEADING：當(dāng)前Server即為選舉出來(lái)的leader。
? FOLLOWING：leader已經(jīng)選舉出來(lái)，當(dāng)前Server與之同步。
? OBSERVING：observer的行為在大多數(shù)情況下與follower完全一致，但是他們不參加選舉和投票，而僅僅接受(observing)選舉和投票的結(jié)果。
Leader Election
當(dāng)leader崩潰或者leader失去大多數(shù)的follower，這時(shí)候zk進(jìn)入恢復(fù)模式，恢復(fù)模式需要重新選舉出一個(gè)新的leader，讓所有的Server都恢復(fù)到一個(gè)正確的狀態(tài)。
Zk的選舉算法有兩種：一種是基于basic paxos實(shí)現(xiàn)的，另外一種是基于fast paxos算法實(shí)現(xiàn)的。
系統(tǒng)默認(rèn)的選舉算法為fast paxos。先介紹basic paxos流程：
1. 選舉線程由當(dāng)前Server發(fā)起選舉的線程擔(dān)任，其主要功能是對(duì)投票結(jié)果進(jìn)行統(tǒng)計(jì)，并選出推薦的Server；
2. 選舉線程首先向所有Server發(fā)起一次詢問（包括自己）；
3. 選舉線程收到回復(fù)后，驗(yàn)證是否是自己發(fā)起的詢問（驗(yàn)證zxid是否一致），然后獲取對(duì)方的id（myid），并存儲(chǔ)到當(dāng)前詢問對(duì)象列表中，最后獲取對(duì)方提議的leader相關(guān)信息（id,zxid），并將這些信息存儲(chǔ)到當(dāng)次選舉的投票記錄表中；
4. 收到所有Server回復(fù)以后，就計(jì)算出zxid最大的那個(gè)Server，并將這個(gè)Server相關(guān)信息設(shè)置成下一次要投票的Server；
5. 線程將當(dāng)前zxid最大的Server設(shè)置為當(dāng)前Server要推薦的Leader，如果此時(shí)獲勝的Server獲得n/2 + 1的Server票數(shù)，設(shè)置當(dāng)前推薦的leader為獲勝的Server，將根據(jù)獲勝的Server相關(guān)信息設(shè)置自己的狀態(tài)，否則，繼續(xù)這個(gè)過(guò)程，直到leader被選舉出來(lái)。
通過(guò)流程分析我們可以得出：要使Leader獲得多數(shù)Server的支持，則Server總數(shù)必須是奇數(shù)2n+1，且存活的Server的數(shù)目不得少于n+1.
每個(gè)Server啟動(dòng)后都會(huì)重復(fù)以上流程。在恢復(fù)模式下，如果是剛從崩潰狀態(tài)恢復(fù)的或者剛啟動(dòng)的server還會(huì)從磁盤快照中恢復(fù)數(shù)據(jù)和會(huì)話信息，zk會(huì)記錄事務(wù)日志并定期進(jìn)行快照，方便在恢復(fù)時(shí)進(jìn)行狀態(tài)恢復(fù)。
fast paxos流程是在選舉過(guò)程中，某Server首先向所有Server提議自己要成為leader，當(dāng)其它Server收到提議以后，解決epoch和zxid的沖突，并接受對(duì)方的提議，然后向?qū)Ψ桨l(fā)送接受提議完成的消息，重復(fù)這個(gè)流程，最后一定能選舉出Leader。
Leader工作流程
Leader主要有三個(gè)功能：
1.恢復(fù)數(shù)據(jù)；
2.維持與follower的心跳，接收f(shuō)ollower請(qǐng)求并判斷follower的請(qǐng)求消息類型；
3.follower的消息類型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，根據(jù)不同的消息類型，進(jìn)行不同的處理。
說(shuō)明：
PING消息是指follower的心跳信息；REQUEST消息是follower發(fā)送的提議信息，包括寫請(qǐng)求及同步請(qǐng)求；
ACK消息是follower的對(duì)提議的回復(fù)，超過(guò)半數(shù)的follower通過(guò)，則commit該提議；
REVALIDATE消息是用來(lái)延長(zhǎng)SESSION有效時(shí)間。
Follower工作流程
Follower主要有四個(gè)功能：
1.向Leader發(fā)送請(qǐng)求（PING消息、REQUEST消息、ACK消息、REVALIDATE消息）；
2.接收Leader消息并進(jìn)行處理；
3.接收Client的請(qǐng)求，如果為寫請(qǐng)求，發(fā)送給Leader進(jìn)行投票；
4.返回Client結(jié)果。
Follower的消息循環(huán)處理如下幾種來(lái)自Leader的消息：
1.PING消息：心跳消息
2.PROPOSAL消息：Leader發(fā)起的提案，要求Follower投票
3.COMMIT消息：服務(wù)器端最新一次提案的信息
4.UPTODATE消息：表明同步完成
5.REVALIDATE消息：根據(jù)Leader的REVALIDATE結(jié)果，關(guān)閉待revalidate的session還是允許其接受消息
6.SYNC消息：返回SYNC結(jié)果到客戶端，這個(gè)消息最初由客戶端發(fā)起，用來(lái)強(qiáng)制得到最新的更新。
Zab: Broadcasting State Updates
Zookeeper Server接收到一次request，如果是follower，會(huì)轉(zhuǎn)發(fā)給leader，Leader執(zhí)行請(qǐng)求并通過(guò)Transaction的形式廣播這次執(zhí)行。
Zookeeper集群如何決定一個(gè)Transaction是否被commit執(zhí)行？通過(guò)“兩段提交協(xié)議”（a two-phase commit）：
? Leader給所有的follower發(fā)送一個(gè)PROPOSAL消息。
? 一個(gè)follower接收到這次PROPOSAL消息，寫到磁盤，發(fā)送給leader一個(gè)ACK消息，告知已經(jīng)收到。
? 當(dāng)Leader收到法定人數(shù)（quorum）的follower的ACK時(shí)候，發(fā)送commit消息執(zhí)行。
Zab協(xié)議保證：
? 如果leader以T1和T2的順序廣播，那么所有的Server必須先執(zhí)行T1，再執(zhí)行T2。
? 如果任意一個(gè)Server以T1、T2的順序commit執(zhí)行，其他所有的Server也必須以T1、T2的順序執(zhí)行。
“兩段提交協(xié)議”最大的問題是如果Leader發(fā)送了PROPOSAL消息后crash或暫時(shí)失去連接，會(huì)導(dǎo)致整個(gè)集群處在一種不確定的狀態(tài)（follower不知道該放棄這次提交還是執(zhí)行提交）。
Zookeeper這時(shí)會(huì)選出新的leader，請(qǐng)求處理也會(huì)移到新的leader上，不同的leader由不同的epoch標(biāo)識(shí)。切換Leader時(shí)，需要解決下面兩個(gè)問題：
1. Never forget delivered messages
Leader在COMMIT投遞到任何一臺(tái)follower之前crash，只有它自己commit了。新Leader必須保證這個(gè)事務(wù)也必須commit。
2. Let go of messages that are skipped
Leader產(chǎn)生某個(gè)proposal，但是在crash之前，沒有follower看到這個(gè)proposal。該server恢復(fù)時(shí)，必須丟棄這個(gè)proposal。
Zookeeper會(huì)盡量保證不會(huì)同時(shí)有2個(gè)活動(dòng)的Leader，因?yàn)?個(gè)不同的Leader會(huì)導(dǎo)致集群處在一種不一致的狀態(tài)，所以Zab協(xié)議同時(shí)保證：
? 在新的leader廣播Transaction之前，先前Leader commit的Transaction都會(huì)先執(zhí)行。
? 在任意時(shí)刻，都不會(huì)有2個(gè)Server同時(shí)有法定人數(shù)（quorum）的支持者。
這里的quorum是一半以上的Server數(shù)目，確切的說(shuō)是有投票權(quán)力的Server（不包括Observer）。
總結(jié)
簡(jiǎn)單介紹了Zookeeper的基本原理，數(shù)據(jù)模型，Session，Watch機(jī)制，一致性保證，Leader Election，Leader和Follower的工作流程和Zab協(xié)議。
