一.ZooKeeper是啥

ZooKeeper概念

　　ZooKeeper是一個開源的分布式協(xié)調(diào)服務(wù)(a service for coordinating processes of distributed applications)，由雅虎公司創(chuàng)建，是Google Chubby的開源實現(xiàn)（Google Chubby是有名的分布式鎖服務(wù)，GFS和Big Table等大型系統(tǒng)都用它來解決分布式協(xié)調(diào)、Master選舉等一系列與分布式鎖服務(wù)相關(guān)的問題）。分布式程序可以基于ZooKeeper實現(xiàn)負(fù)載均衡，命名服務(wù)，分布式鎖等功能。ZooKeeper將全量數(shù)據(jù)都存在內(nèi)存中，實現(xiàn)提高服務(wù)器吞吐、減少延遲的目的。

　　上面的英文說的足夠簡而意賅了，a service for coordinating processes of distributed applications。是為了協(xié)調(diào)分布式應(yīng)用的，到底解決什么樣的問題呢。相信大家的Java基礎(chǔ)都不錯，個人覺得還是拿鎖舉例子比較好理解，在單機(jī)式中，我們想保證多個線程爭搶，最后只有一個線程爭搶到執(zhí)行權(quán)（鎖）并執(zhí)行你想要讓他做的業(yè)務(wù)代碼，最簡單的方式，可以用：

synchronized (obj){
    //業(yè)務(wù)邏輯
}

　　那么在分布式的情況下呢？怎么保證，同一個服務(wù)部署在不同機(jī)器上實現(xiàn)如上目標(biāo)呢？那么這就是分布式協(xié)調(diào)服務(wù)要干的事情。分布式協(xié)調(diào)遠(yuǎn)遠(yuǎn)比同一個進(jìn)程里的協(xié)調(diào)復(fù)雜得多，所以類似Zookeeper這類分布式協(xié)調(diào)服務(wù)就應(yīng)運而生。在解決分布式數(shù)據(jù)一致性上，除了ZooKeeper，目前沒有一個成熟穩(wěn)定且被大規(guī)模應(yīng)用的開源方案。且越來越多的大型分布式項目如HBase、Storm都已經(jīng)使用ZooKeeper作為其核心組件，用于分布式協(xié)調(diào)。

　　ZooKeeper可以保證如下分布式一致性特性：

順序一致性：從同一客戶端發(fā)起的事務(wù)請求，最終將會嚴(yán)格地按照其發(fā)起順序被應(yīng)用到ZooKeeper中
原子性：要么整個集群所有機(jī)器都成功應(yīng)用了某個事務(wù)，要么都沒有應(yīng)用
單系統(tǒng)鏡像：無論客戶端連接的是哪個ZooKeeper服務(wù)器，其看到的服務(wù)器數(shù)據(jù)模型都是一致的（當(dāng)然，ZooKeeper就是解決分布式數(shù)據(jù)一致性問題的）
可靠性：一個服務(wù)端成功地應(yīng)用了一個事務(wù)，并完成對客戶端的響應(yīng)，那么該事務(wù)所引起的服務(wù)端狀態(tài)變更將會被一致保留下來，除非有另一個事務(wù)又對其進(jìn)行了變更
實時性：ZooKeeper僅保證在一定時間段內(nèi)，客戶端最終一定能從服務(wù)端上讀取到最新的數(shù)據(jù)狀態(tài)。也就是說比方說一個ZooKeeper集群，有一個時間點，數(shù)據(jù)在集群中的每個服務(wù)器不是一致的，ZooKeeper只保證最終一致性,但是實時的一致性可以由客戶端調(diào)用自己來保證,通過調(diào)用sync()方法

ZooKeeper名字誕生

　　在立項初期，考慮到之前內(nèi)部很多項目都是使用動物的名字來命名的（例如著名的Pig項目)，雅虎的工程師希望給這個項目也取一個動物的名字。時任研究院的首席科學(xué)家 Raghu Ramakrishnan 開玩笑地說：“在這樣下去，我們這兒就變成動物園了！”此話一出，大家紛紛表示就叫動物園管理員吧，因為各個以動物命名的分布式組件放在一起，雅虎的整個分布式系統(tǒng)看上去就像一個大型的動物園了。而 Zookeeper 正好要用來進(jìn)行分布式環(huán)境的協(xié)調(diào)，于是，Zookeeper 的名字也就由此誕生了。

ZooKeeper的核心概念

集群角色

　　在ZooKeeper中，集群有3個角色：Leader、Follower和Observer三種角色。

　　Leader：ZooKeeper集群中所有機(jī)器通過選舉過程選定集群中的一臺機(jī)器為Leader，事務(wù)請求唯一調(diào)度者和處理者，保證集群事務(wù)處理的順序性

　　Follower：為客戶端提供讀服務(wù)、參與Leader選舉過程、參與寫操作的“過半寫成功”策略，收到寫事務(wù)請求直接轉(zhuǎn)發(fā)給Leader

　　Observer：為客戶端提供讀服務(wù)，在不影響集群事務(wù)處理能力的前提下提升集群的非事務(wù)處理能力

會話

　　Session是ZooKeeper中的會話實體，代表了一個客戶端會話，一個客戶端連接指客戶端和服務(wù)器之間的一個TCP長連接。通過這個連接，客戶端能夠做以下事情

　　-　　向ZooKeeper服務(wù)器發(fā)送請求并接收響應(yīng)

　　-　　心跳檢測

　　-　　接收來自服務(wù)器的Watch事件

數(shù)據(jù)節(jié)點（Znode）

　　數(shù)據(jù)節(jié)點（Znode）是指數(shù)據(jù)模型中的數(shù)據(jù)單元，ZooKeeper內(nèi)存數(shù)據(jù)存儲的核心是DataTree，是一個樹的數(shù)據(jù)結(jié)構(gòu)，代表了內(nèi)存中的一份完整的數(shù)據(jù)，由斜杠"/"進(jìn)行分割的路徑，就是一個Znode，每個Znode都保存自己的數(shù)據(jù)內(nèi)容

版本

　　每個Znode都有三種類型的版本信息，對節(jié)點數(shù)據(jù)變動會引起版本號變化

　　version：當(dāng)前數(shù)據(jù)節(jié)點數(shù)據(jù)內(nèi)容的版本號

　　cversion：當(dāng)前數(shù)據(jù)節(jié)點子節(jié)點的版本號

　　aversion：當(dāng)前數(shù)據(jù)節(jié)點ACL變更版本號

Watcher

　　事件監(jiān)聽器（Watcher）是ZooKeeper非常重要的特性，我們可以在節(jié)點上注冊Watcher，并且在一些特性事件觸發(fā)時候，服務(wù)器將事件通知到客戶端上

ACL

　　ZooKeeper使用ACL（Access Control Lists）權(quán)限控制機(jī)制保證數(shù)據(jù)安全，有5個權(quán)限：

　　CREATE：創(chuàng)建子節(jié)點的權(quán)限

　　READ：獲取節(jié)點數(shù)據(jù)和子節(jié)點列表的權(quán)限

　　WRITE：更新節(jié)點數(shù)據(jù)的權(quán)限

　　DELETE：刪除子節(jié)點的權(quán)限

　　ADMIN：設(shè)置節(jié)點ACL的權(quán)限

二.ZooKeeper能做啥

　　我們可以回頭看最上面的圖，Hbase，Hadoop，Kafka等已經(jīng)被廣泛應(yīng)用在越來越多的大型分布式系統(tǒng)中，用來解決諸如配置管理，分布式通知/協(xié)調(diào)、集群管理和Master選舉等一系列分布式問題

　　ZooKeeper在阿里的實踐有Dubbo，消息中間件Metamorphosis，分布式數(shù)據(jù)庫同步系統(tǒng)Otter，實時計算引擎Jstorm等

數(shù)據(jù)發(fā)布/訂閱（配置中心）
負(fù)載均衡
分布式協(xié)調(diào)/通知
集群管理
Master選舉
分布式鎖

三.ZAB協(xié)議是啥

　　可以這么說，No ZAB，No ZooKeeper。ZAB協(xié)議是整個ZooKeeper框架的核心所在。

　　ZooKeeper是一個高可用的分布式數(shù)據(jù)管理與協(xié)調(diào)框架。基于對ZAB算法的實現(xiàn)，ZooKeeper成為了解決分布式環(huán)境中數(shù)據(jù)的一致性問題的利器。ZAB協(xié)議的全稱是ZooKeeper Atomic Broadcast（ZooKeeper原子消息廣播協(xié)議）。ZAB協(xié)議是一種特別為ZooKeeper設(shè)計的崩潰可恢復(fù)的原子消息廣播算法。

　　所有事務(wù)請求必須由唯一的Leader服務(wù)器來協(xié)調(diào)處理，其他服務(wù)器則成為Follower服務(wù)器。Leader服務(wù)器負(fù)責(zé)將事務(wù)請求轉(zhuǎn)換成一個提議，并將該提議分發(fā)到集群中的所有Follower服務(wù)器，之后Leader服務(wù)器需要等待所有Follower的響應(yīng)，一旦超過半數(shù)的Follower服務(wù)器進(jìn)行了正確的反饋后（不需要等待集群中所有的Follower服務(wù)器都反饋響應(yīng)），那么Leader就會再次向所有Follower服務(wù)器分發(fā)Commit消息，要求對前一個提議進(jìn)行提交。

術(shù)語解釋

　　首先先來看一下選舉算法出現(xiàn)的一些專有術(shù)語

SID：服務(wù)器ID

　　SID是一個數(shù)據(jù)，標(biāo)識一臺ZooKeeper集群中的機(jī)器，SID不能重復(fù)，和myid值一樣。（集群的配置文件中，server.id=host:port:port，這里的id就是myid，我們還需要在dataDir參數(shù)的目錄創(chuàng)建myid文件，就是這里的id）

ZXID：事務(wù)ID

　　ZXID是一個事務(wù)ID，標(biāo)記唯一一次服務(wù)器狀態(tài)的變更，某一時刻，集群中的每臺機(jī)器的ZXID不一定都一致，之前已經(jīng)說過了。它是一個64位的數(shù)字，低32位可以看作遞增計數(shù)器，高32位代表Leader周期epoch的編號

Vote：投票

　　我們可以看下Vote的數(shù)據(jù)結(jié)構(gòu)：

　　接下來我們來解釋一下每個字段的意思：

　　id：被選舉的Leader的SID值

　　zxid：被選舉的Leader的事務(wù)ID

　　electionEpoch：邏輯時鐘

　　peerEpoch：被選舉的Leader的epoch

　　state：當(dāng)前服務(wù)器的狀態(tài)

Quorum：過半機(jī)器數(shù)

　　quorum=（n/2+1），假如集群總數(shù)是3，那么quorum就是2

ZAB協(xié)議三個階段

階段一：發(fā)現(xiàn)

　　階段一就是Leader選舉過程（服務(wù)器啟動期間或者服務(wù)器運行期間），服務(wù)器的狀態(tài)進(jìn)入LOCKING狀態(tài)。進(jìn)入選舉Leader流程。

　　不要死記硬背具體規(guī)則，總結(jié)簡單來說，哪臺服務(wù)器上的數(shù)據(jù)較新，也就是它的ZXID越大，那么越有可能成為Leader。如果幾個服務(wù)器具有相同的ZXID，那么SID較大的服務(wù)器成為Leader。

　　規(guī)則1：如果收到投票的ZXID大于自身的ZXID，就認(rèn)可收到的投票再次投出去

　　規(guī)則2：如果收到投票的ZXID小于自身的ZXID，則堅持自己的投票不做任何變更

　　規(guī)則3：如果收到投票的ZXID等于自身的ZXID，則對比兩者SID，如果收到投票的SID大于自身的SID則認(rèn)可收到的投票再次投出去

　　規(guī)則4：如果收到投票的ZXID等于自身的ZXID，并且收到投票的SID小于自身SID則堅持自己的投票不做任何變更

　　接下來舉個例子來說明選舉的過程：

　　過程A：我們假設(shè)ZooKeeper由5臺機(jī)器組成，SID分別為1，2，3，4，5。ZXID分別為9，9，9，8，8。此時SID為2的機(jī)器是Leader服務(wù)器，某一時刻SID為1和2的機(jī)器出現(xiàn)故障，因此集群開始進(jìn)行Leader選舉，state切換到LOCKING狀態(tài)。

　　過程B：第一次投票，每臺機(jī)器都選自己作為被選舉的對象來進(jìn)行投票，所以SID為3，4，5的投票情況為（這里Vote做簡化，只有SID和ZXID）：（3，9），（4，8），（5，8）。

　　過程C：Server3收到（4，8）和（5，8）。根據(jù)規(guī)則2，不做任何投票的變更。

　　　　　 Server4收到（3，9）和（5，8）。根據(jù)規(guī)則1，需要變更投票為（3，9）。

　　　　 Server5同樣的變更投票為（3，9）。

　　過程D：第二輪投票后，Server3收到超過一半的票數(shù)，成為Leader

階段二：同步

　　選舉完成后，Leader服務(wù)器會為每一個Follower服務(wù)器都準(zhǔn)備一個隊列，并將那些沒有被各Follower服務(wù)器同步的事務(wù)以Proposal消息的形式逐個發(fā)送給Follower服務(wù)器，然后在提議消息之后緊接發(fā)送一個Commit消息，表示該事務(wù)被提交，等到Follower服務(wù)器都將未同步的事務(wù)從Leader服務(wù)器同步過來并成功應(yīng)用到本地數(shù)據(jù)庫后，Leader服務(wù)器會將該Follower服務(wù)器加入真正可用的Follower列表中

階段三：廣播

　　Leader服務(wù)器會給每個Follower分配一個FIFO的隊列來分送事務(wù)，F(xiàn)ollower服務(wù)器收到事務(wù)Proposal之后以事務(wù)日志的形式寫入本地磁盤，寫入成功會給Leader服務(wù)器回復(fù)一個ACK。

　　當(dāng)Leader服務(wù)器收到過半的ACK響應(yīng)則廣播發(fā)送Commit消息給所有Follower，然后所有服務(wù)器完成對事務(wù)的提交。

總結(jié)

以上是生活随笔為你收集整理的搞懂ZooKeeper到底是做啥的的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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