簡(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可以是臨時(shí)節(jié)點(diǎn)（EPHEMERAL）孽惰，可以是持久節(jié)點(diǎn)（PERSISTENT）晚岭。如果創(chuàng)建的是臨時(shí)節(jié)點(diǎn)，一旦創(chuàng)建這個(gè)EPHEMERALznode的客戶端與服務(wù)器失去聯(lián)系勋功，這個(gè)znode也將自動(dòng)刪除坦报，Zookeeper的客戶端和服務(wù)器通信采用長(zhǎng)連接方式，每個(gè)客戶端和服務(wù)器通過心跳來(lái)保持連接狂鞋，這個(gè)連接狀態(tài)稱為session片择，如果znode是臨時(shí)節(jié)點(diǎn)，這個(gè)session失效骚揍，znode也就刪除了字管。

5）znode的目錄名可以自動(dòng)編號(hào)，如App1已經(jīng)存在信不，再創(chuàng)建的話嘲叔，將會(huì)自動(dòng)命名為App2。

6）znode可以被監(jiān)控浑塞，包括這個(gè)目錄節(jié)點(diǎn)中存儲(chǔ)的數(shù)據(jù)的修改借跪，子節(jié)點(diǎn)目錄的變化等，一旦變化可以通知設(shè)置監(jiān)控的客戶端酌壕，這個(gè)是Zookeeper的核心特性，Zookeeper的很多功能都是基于這個(gè)特性實(shí)現(xiàn)的歇由。

7）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ù)端是通過 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)視，
  • 一次成功的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)說這通常是透明的蓄诽。只有一種情況會(huì)導(dǎo)致監(jiān)視事件的丟失，即：通過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在工作過程中有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è)過程畏铆，直到leader被選舉出來(lái)。

通過流程分析我們可以得出：要使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流程是在選舉過程中倚搬，某Server首先向所有Server提議自己要成為leader冶共，當(dāng)其它Server收到提議以后，解決epoch和zxid的沖突每界，并接受對(duì)方的提議捅僵，然后向?qū)Ψ桨l(fā)送接受提議完成的消息，重復(fù)這個(gè)流程眨层，最后一定能選舉出Leader庙楚。

Leader工作流程

Leader主要有三個(gè)功能：

• 1.恢復(fù)數(shù)據(jù)；
• 2.維持與follower的心跳趴樱，接收follower請(qǐng)求并判斷follower的請(qǐng)求消息類型馒闷；
• 3.follower的消息類型主要有PING消息、REQUEST消息叁征、ACK消息纳账、REVALIDATE消息，根據(jù)不同的消息類型捺疼，進(jìn)行不同的處理疏虫。

PING消息是指follower的心跳信息；
REQUEST消息是follower發(fā)送的提議信息啤呼，包括寫請(qǐng)求及同步請(qǐng)求卧秘；
ACK消息是follower的對(duì)提議的回復(fù)，超過半數(shù)的follower通過官扣，則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)求并通過Transaction的形式廣播這次執(zhí)行橘券。Zookeeper集群如何決定一個(gè)Transaction是否被commit執(zhí)行？通過“兩段提交協(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é)議保證：

1） 如果leader以T1和T2的順序廣播磺樱，那么所有的Server必須先執(zhí)行T1，再執(zhí)行T2婆咸。
2） 如果任意一個(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è)問題：

• Never forget delivered messages
  Leader在COMMIT投遞到任何一臺(tái)follower之前crash，只有它自己commit了警儒。新Leader必須保證這個(gè)事務(wù)也必須commit训裆。

• 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í)保證：

1） 在新的leader廣播Transaction之前厌丑，先前Leader commit的Transaction都會(huì)先執(zhí)行定欧。
2） 在任意時(shí)刻渔呵，都不會(huì)有2個(gè)Server同時(shí)有法定人數(shù)（quorum）的支持者。

Ref：
http://www.cnblogs.com/luxiaoxun/p/4887452.html