Zookeeper

ZooKeeper 是 Apache 軟件基金會的一個軟件項目，它為大型分布式計算提供開源的分布式配置服務(wù)、同步服務(wù)和命名注冊。ZooKeeper 曾經(jīng)是 Hadoop 的一個子項目，現(xiàn)在是一個頂級獨立的開源項目。

1、Zookeeper的角色

• 領(lǐng)導(dǎo)者（leader），負責進行投票的發(fā)起和決議，更新系統(tǒng)狀態(tài)。
• 學(xué)習(xí)者（learner），包括跟隨者（follower）和觀察者（bserver），follower用于接受客戶端請求并想客戶端返回結(jié)果，在選主過程中參與投票
• Observer可以接受客戶端連接，將寫請求轉(zhuǎn)發(fā)給leader，但observer不參加投票過程，只同步leader的狀態(tài)，observer的目的是為了擴展系統(tǒng)，提高讀取速度
• 客戶端（client），請求發(fā)起方

編輯

?Zookeeper的核心是原子廣播，這個機制保證了各個Server之間的同步。實現(xiàn)這個機制的協(xié)議叫做Zab協(xié)議。Zab協(xié)議有兩種模式，它們分別是恢復(fù)模式（選主）和廣播模式（同步）。當服務(wù)啟動或者在領(lǐng)導(dǎo)者崩潰后，Zab就進入了恢復(fù)模式，當領(lǐng)導(dǎo)者被選舉出來，且大多數(shù)Server完成了和leader的狀態(tài)同步以后，恢復(fù)模式就結(jié)束了。狀態(tài)同步保證了leader和Server具有相同的系統(tǒng)狀態(tài)。

編輯

為了保證事務(wù)的順序一致性，zookeeper采用了遞增的事務(wù)id號(zxid）來標識事務(wù)。所有的提議（proposal）都在被提出的時候加上了zxid。實現(xiàn)中zxid是一個64位的數(shù)字，它高32位是epoch用來標識leader關(guān)系是否改變，每次一個leader被選出來，它都會有一個新的epoch，標識當前屬于那個leader的統(tǒng)治時期。第32位用于遞增計數(shù)。

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

• LOOKING：當前Server不知道leader是誰，正在搜尋
• LEADING：當前Server即為選舉出來的leader
• FOLLOWING：leader已經(jīng)選舉出來，當前Server與之同步

2、Zookeeper 的讀寫機制

*Zookeeper是一個由多個server組成的集群 *一個leader，多個follower *每個server保存一份數(shù)據(jù)副本 *全局數(shù)據(jù)一致 *分布式讀寫 *更新請求轉(zhuǎn)發(fā)，由leader實施

3、Zookeeper 的保證

* 更新請求順序進行，來自同一個client的更新請求按其發(fā)送順序依次執(zhí)行。 * 數(shù)據(jù)更新原子性，一次數(shù)據(jù)更新要么成功，要么失敗。 * 全局唯一數(shù)據(jù)視圖，client無論連接到哪個server，數(shù)據(jù)視圖都是一致的。 * 實時性，在一定事件范圍內(nèi)，client能讀到最新數(shù)據(jù)。

4、Zookeeper節(jié)點數(shù)據(jù)操作流程

注：

• 1.在Client向Follwer發(fā)出一個寫的請求
• 2.Follwer把請求發(fā)送給Leader
• 3.Leader接收到以后開始發(fā)起投票并通知Follwer進行投票
• 4.Follwer把投票結(jié)果發(fā)送給Leader
• 5.Leader將結(jié)果匯總后如果需要寫入，則開始寫入同時把寫入操作通知給Leader，然后commit;
• 6.Follwer把請求結(jié)果返回給Client

? 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消息：服務(wù)器端最新一次提案的信息；
• ?4 .UPTODATE消息：表明同步完成；
• 5 .REVALIDATE消息：根據(jù)Leader的REVALIDATE結(jié)果，關(guān)閉待revalidate的session還是允許其接受消息；
• ?6 .SYNC消息：返回SYNC結(jié)果到客戶端，這個消息最初由客戶端發(fā)起，用來強制得到最新的更新。

5、Zookeeper leader 選舉

??半數(shù)通過

– 3臺機器 掛一臺 2>3/2

– 4臺機器 掛2臺 2！>4/2

? A提案說，我要選自己，B你同意嗎？C你同意嗎？B說，我同意選A；C說，我同意選A。(注意，這里超過半數(shù)了，其實在現(xiàn)實世界選舉已經(jīng)成功了。

但是計算機世界是很嚴格，另外要理解算法，要繼續(xù)模擬下去。)

? 接著B提案說，我要選自己，A你同意嗎；A說，我已經(jīng)超半數(shù)同意當選，你的提案無效；C說，A已經(jīng)超半數(shù)同意當選，B提案無效。

? 接著C提案說，我要選自己，A你同意嗎；A說，我已經(jīng)超半數(shù)同意當選，你的提案無效；B說，A已經(jīng)超半數(shù)同意當選，C的提案無效。

? 選舉已經(jīng)產(chǎn)生了Leader，后面的都是follower，只能服從Leader的命令。而且這里還有個小細節(jié)，就是其實誰先啟動誰當頭。

?6、zxid

? znode節(jié)點的狀態(tài)信息中包含czxid, 那么什么是zxid呢?

? ZooKeeper狀態(tài)的每一次改變, 都對應(yīng)著一個遞增的Transaction id, 該id稱為zxid. 由于zxid的遞增性質(zhì), 如果zxid1小于zxid2, 那么zxid1肯定先于zxid2發(fā)生.

創(chuàng)建任意節(jié)點, 或者更新任意節(jié)點的數(shù)據(jù), 或者刪除任意節(jié)點, 都會導(dǎo)致Zookeeper狀態(tài)發(fā)生改變, 從而導(dǎo)致zxid的值增加.

7、Zookeeper工作原理

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

當服務(wù)啟動或者在領(lǐng)導(dǎo)者崩潰后，Zab就進入了恢復(fù)模式，當領(lǐng)導(dǎo)者被選舉出來，且大多數(shù)server的完成了和leader的狀態(tài)同步以后，恢復(fù)模式就結(jié)束了。

狀態(tài)同步保證了leader和server具有相同的系統(tǒng)狀態(tài)

? 一旦leader已經(jīng)和多數(shù)的follower進行了狀態(tài)同步后，他就可以開始廣播消息了，即進入廣播狀態(tài)。這時候當一個server加入zookeeper服務(wù)中，它會在恢復(fù)模式下啟動，

發(fā)現(xiàn)leader，并和leader進行狀態(tài)同步。待到同步結(jié)束，它也參與消息廣播。Zookeeper服務(wù)一直維持在Broadcast狀態(tài)，直到leader崩潰了或者leader失去了大部分的followers支持。

? 廣播模式需要保證proposal被按順序處理，因此zk采用了遞增的事務(wù)id號(zxid)來保證。所有的提議(proposal)都在被提出的時候加上了zxid。

實現(xiàn)中zxid是一個64位的數(shù)字，它高32位是epoch用來標識leader關(guān)系是否改變，每次一個leader被選出來，它都會有一個新的epoch。第32位是個遞增計數(shù)。

? 當leader崩潰或者leader失去大多數(shù)的follower，這時候zk進入恢復(fù)模式，恢復(fù)模式需要重新選舉出一個新的leader，讓所有的server都恢復(fù)到一個正確的狀態(tài)。

? 每個Server啟動以后都詢問其它的Server它要投票給誰。

? 對于其他server的詢問，server每次根據(jù)自己的狀態(tài)都回復(fù)自己推薦的leader的id和上一次處理事務(wù)的zxid（系統(tǒng)啟動時每個server都會推薦自己）

? 收到所有Server回復(fù)以后，就計算出zxid最大的哪個Server，并將這個Server相關(guān)信息設(shè)置成下一次要投票的Server。

? 計算這過程中獲得票數(shù)最多的的sever為獲勝者，如果獲勝者的票數(shù)超過半數(shù)，則該server被選為leader。否則，繼續(xù)這個過程，直到leader被選舉出來

? leader就會開始等待server連接

? Follower連接leader，將最大的zxid發(fā)送給leader

? Leader根據(jù)follower的zxid確定同步點

? 完成同步后通知follower 已經(jīng)成為uptodate狀態(tài)

? Follower收到uptodate消息后，又可以重新接受client的請求進行服務(wù)了

8、數(shù)據(jù)一致性與paxos 算法

? 據(jù)說Paxos算法的難理解與算法的知名度一樣令人敬仰，所以我們先看如何保持數(shù)據(jù)的一致性，這里有個原則就是：

? 在一個分布式數(shù)據(jù)庫系統(tǒng)中，如果各節(jié)點的初始狀態(tài)一致，每個節(jié)點都執(zhí)行相同的操作序列，那么他們最后能得到一個一致的狀態(tài)。

? Paxos算法解決的什么問題呢，解決的就是保證每個節(jié)點執(zhí)行相同的操作序列。好吧，這還不簡單，master維護一個

全局寫隊列，所有寫操作都必須 放入這個隊列編號，那么無論我們寫多少個節(jié)點，只要寫操作是按編號來的，就能保證一

致性。沒錯，就是這樣，可是如果master掛了呢。

? Paxos算法通過投票來對寫操作進行全局編號，同一時刻，只有一個寫操作被批準，同時并發(fā)的寫操作要去爭取選票，

只有獲得過半數(shù)選票的寫操作才會被 批準（所以永遠只會有一個寫操作得到批準），其他的寫操作競爭失敗只好再發(fā)起一

輪投票，就這樣，在日復(fù)一日年復(fù)一年的投票中，所有寫操作都被嚴格編號排 序。編號嚴格遞增，當一個節(jié)點接受了一個

編號為100的寫操作，之后又接受到編號為99的寫操作（因為網(wǎng)絡(luò)延遲等很多不可預(yù)見原因），它馬上能意識到自己 數(shù)據(jù)

不一致了，自動停止對外服務(wù)并重啟同步過程。任何一個節(jié)點掛掉都不會影響整個集群的數(shù)據(jù)一致性（總2n+1臺，除非掛掉大于n臺）。

推薦書籍：《從Paxos到Zookeeper分布式一致性原理與實踐》

9、Observer

? Zookeeper需保證高可用和強一致性；

? 為了支持更多的客戶端，需要增加更多Server；

? Server增多，投票階段延遲增大，影響性能；

? 權(quán)衡伸縮性和高吞吐率，引入Observer

? Observer不參與投票；

? Observers接受客戶端的連接，并將寫請求轉(zhuǎn)發(fā)給leader節(jié)點；

? 加入更多Observer節(jié)點，提高伸縮性，同時不影響吞吐率

10、 為什么zookeeper集群的數(shù)目，一般為奇數(shù)個？

?Leader選舉算法采用了Paxos協(xié)議；

?Paxos核心思想：當多數(shù)Server寫成功，則任務(wù)數(shù)據(jù)寫成功如果有3個Server，則兩個寫成功即可；如果有4或5個Server，則三個寫成功即可。

?Server數(shù)目一般為奇數(shù)（3、5、7）如果有3個Server，則最多允許1個Server掛掉；如果有4個Server，則同樣最多允許1個Server掛掉由此，

我們看出3臺服務(wù)器和4臺服務(wù)器的的容災(zāi)能力是一樣的，所以為了節(jié)省服務(wù)器資源，一般我們采用奇數(shù)個數(shù)，作為服務(wù)器部署個數(shù)。

11、Zookeeper 的數(shù)據(jù)模型

? 層次化的目錄結(jié)構(gòu)，命名符合常規(guī)文件系統(tǒng)規(guī)范

? 每個節(jié)點在zookeeper中叫做znode,并且其有一個唯一的路徑標識

? 節(jié)點Znode可以包含數(shù)據(jù)和子節(jié)點，但是EPHEMERAL類型的節(jié)點不能有子節(jié)點

? Znode中的數(shù)據(jù)可以有多個版本，比如某一個路徑下存有多個數(shù)據(jù)版本，那么查詢這個路徑下的數(shù)據(jù)就需要帶上版本

? 客戶端應(yīng)用可以在節(jié)點上設(shè)置監(jiān)視器

? 節(jié)點不支持部分讀寫，而是一次性完整讀寫

12、Zookeeper 的節(jié)點

? Znode有兩種類型，短暫的（ephemeral）和持久的（persistent）

? Znode的類型在創(chuàng)建時確定并且之后不能再修改

? 短暫znode的客戶端會話結(jié)束時，zookeeper會將該短暫znode刪除，短暫znode不可以有子節(jié)點

? 持久znode不依賴于客戶端會話，只有當客戶端明確要刪除該持久znode時才會被刪除

? Znode有四種形式的目錄節(jié)點

? PERSISTENT（持久的）

? EPHEMERAL(暫時的)

? PERSISTENT_SEQUENTIAL（持久化順序編號目錄節(jié)點）

? EPHEMERAL_SEQUENTIAL（暫時化順序編號目錄節(jié)點）

總結(jié)

以上是生活随笔為你收集整理的精髓，深入浅出剖析11个Zookeeper知识点，没有很难的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。