這可能是把ZooKeeper概念講的最清楚的一篇文章

作者：SnailClimb 2018-09-12 09:34:11

相信大家對(duì) ZooKeeper 應(yīng)該不算陌生，但是你真的了解 ZooKeeper 是什么嗎？如果別人/面試官讓你講講 ZooKeeper 是什么，你能回答到哪個(gè)地步呢？

我本人曾經(jīng)使用過 ZooKeeper 作為 Dubbo 的注冊(cè)中心，另外在搭建 Solr 集群的時(shí)候，我使用到了 ZooKeeper 作為 Solr 集群的管理工具。

前幾天，總結(jié)項(xiàng)目經(jīng)驗(yàn)的時(shí)候，我突然問自己 ZooKeeper 到底是個(gè)什么東西？

想了半天，腦海中只是簡單的能浮現(xiàn)出幾句話：

Zookeeper 可以被用作注冊(cè)中心。
Zookeeper 是 Hadoop 生態(tài)系統(tǒng)的一員。
構(gòu)建 Zookeeper 集群的時(shí)候，使用的服務(wù)器最好是奇數(shù)臺(tái)。

可見，我對(duì)于 Zookeeper 的理解僅僅是停留在了表面。所以，通過本文，希望帶大家稍微詳細(xì)的了解一下 ZooKeeper 。

如果沒有學(xué)過 ZooKeeper，那么本文將會(huì)是你進(jìn)入 ZooKeeper 大門的墊腳磚；如果你已經(jīng)接觸過 ZooKeeper ，那么本文將帶你回顧一下 ZooKeeper 的一些基礎(chǔ)概念。

最后，本文只涉及 ZooKeeper 的一些概念，并不涉及 ZooKeeper 的使用以及 ZooKeeper 集群的搭建。

網(wǎng)上有介紹 ZooKeeper 的使用以及搭建 ZooKeeper 集群的文章，大家有需要可以自行查閱。

什么是 ZooKeeper

ZooKeeper 的由來

下面這段內(nèi)容摘自《從 Paxos 到 ZooKeeper 》第四章第一節(jié)的某段內(nèi)容，推薦大家閱讀一下：

Zookeeper 最早起源于雅虎研究院的一個(gè)研究小組。在當(dāng)時(shí)，研究人員發(fā)現(xiàn)，在雅虎內(nèi)部很多大型系統(tǒng)基本都需要依賴一個(gè)類似的系統(tǒng)來進(jìn)行分布式協(xié)調(diào)，但是這些系統(tǒng)往往都存在分布式單點(diǎn)問題。

所以，雅虎的開發(fā)人員就試圖開發(fā)一個(gè)通用的無單點(diǎn)問題的分布式協(xié)調(diào)框架，以便讓開發(fā)人員將精力集中在處理業(yè)務(wù)邏輯上。

關(guān)于“ZooKeeper”這個(gè)項(xiàng)目的名字，其實(shí)也有一段趣聞。在立項(xiàng)初期，考慮到之前內(nèi)部很多項(xiàng)目都是使用動(dòng)物的名字來命名的（例如著名的Pig項(xiàng)目)，雅虎的工程師希望給這個(gè)項(xiàng)目也取一個(gè)動(dòng)物的名字。

時(shí)任研究院的首席科學(xué)家 Raghu Ramakrishnan 開玩笑地說：“在這樣下去，我們這兒就變成動(dòng)物園了！”

此話一出，大家紛紛表示就叫動(dòng)物園管理員吧，因?yàn)楦鱾€(gè)以動(dòng)物命名的分布式組件放在一起，雅虎的整個(gè)分布式系統(tǒng)看上去就像一個(gè)大型的動(dòng)物園了。

而 Zookeeper 正好要用來進(jìn)行分布式環(huán)境的協(xié)調(diào)，于是，Zookeeper 的名字也就由此誕生了。

ZooKeeper 概覽

ZooKeeper 是一個(gè)開源的分布式協(xié)調(diào)服務(wù)，ZooKeeper 框架最初是在“Yahoo!"上構(gòu)建的，用于以簡單而穩(wěn)健的方式訪問他們的應(yīng)用程序。

后來，Apache ZooKeeper 成為 Hadoop，HBase 和其他分布式框架使用的有組織服務(wù)的標(biāo)準(zhǔn)。

例如，Apache HBase 使用 ZooKeeper 跟蹤分布式數(shù)據(jù)的狀態(tài)。

ZooKeeper 的設(shè)計(jì)目標(biāo)是將那些復(fù)雜且容易出錯(cuò)的分布式一致性服務(wù)封裝起來，構(gòu)成一個(gè)高效可靠的原語集，并以一系列簡單易用的接口提供給用戶使用。

原語：操作系統(tǒng)或計(jì)算機(jī)網(wǎng)絡(luò)用語范疇。它是由若干條指令組成的，用于完成一定功能的一個(gè)過程。具有不可分割性，即原語的執(zhí)行必須是連續(xù)的，在執(zhí)行過程中不允許被中斷。

ZooKeeper 是一個(gè)典型的分布式數(shù)據(jù)一致性解決方案，分布式應(yīng)用程序可以基于 ZooKeeper 實(shí)現(xiàn)諸如數(shù)據(jù)發(fā)布/訂閱、負(fù)載均衡、命名服務(wù)、分布式協(xié)調(diào)/通知、集群管理、Master 選舉、分布式鎖和分布式隊(duì)列等功能。

ZooKeeper 一個(gè)最常用的使用場景就是用于擔(dān)任服務(wù)生產(chǎn)者和服務(wù)消費(fèi)者的注冊(cè)中心。

服務(wù)生產(chǎn)者將自己提供的服務(wù)注冊(cè)到 ZooKeeper 中心，服務(wù)的消費(fèi)者在進(jìn)行服務(wù)調(diào)用的時(shí)候先到 ZooKeeper 中查找服務(wù)，獲取到服務(wù)生產(chǎn)者的詳細(xì)信息之后，再去調(diào)用服務(wù)生產(chǎn)者的內(nèi)容與數(shù)據(jù)。

如下圖所示，在 Dubbo 架構(gòu)中 ZooKeeper 就擔(dān)任了注冊(cè)中心這一角色。

Dubbo 架構(gòu)圖

結(jié)合個(gè)人使用講一下 ZooKeeper

在我自己做過的項(xiàng)目中，主要使用到了 ZooKeeper 作為 Dubbo 的注冊(cè)中心(Dubbo 官方推薦使用 ZooKeeper 注冊(cè)中心)。

另外在搭建 Solr 集群的時(shí)候，我使用 ZooKeeper 作為 Solr 集群的管理工具。

這時(shí)，ZooKeeper 主要提供下面幾個(gè)功能：

集群管理：容錯(cuò)、負(fù)載均衡。
配置文件的集中管理。
集群的入口。

我個(gè)人覺得在使用 ZooKeeper 的時(shí)候，最好是使用集群版的 ZooKeeper 而不是單機(jī)版的。

官網(wǎng)給出的架構(gòu)圖就描述的是一個(gè)集群版的 ZooKeeper 。通常 3 臺(tái)服務(wù)器就可以構(gòu)成一個(gè) ZooKeeper 集群了。

為什么最好使用奇數(shù)臺(tái)服務(wù)器構(gòu)成 ZooKeeper 集群？

我們知道在 ZooKeeper 中 Leader 選舉算法采用了 Zab 協(xié)議。Zab 核心思想是當(dāng)多數(shù) Server 寫成功，則任務(wù)數(shù)據(jù)寫成功：

如果有 3 個(gè) Server，則最多允許 1 個(gè) Server 掛掉。
如果有 4 個(gè) Server，則同樣最多允許 1 個(gè) Server 掛掉。

既然 3 個(gè)或者 4 個(gè) Server，同樣最多允許 1 個(gè) Server 掛掉，那么它們的可靠性是一樣的。

所以選擇奇數(shù)個(gè) ZooKeeper Server 即可，這里選擇 3 個(gè) Server。

關(guān)于 ZooKeeper 的一些重要概念

重要概念總結(jié)

關(guān)于 ZooKeeper 的一些重要概念：

ZooKeeper 本身就是一個(gè)分布式程序（只要半數(shù)以上節(jié)點(diǎn)存活，ZooKeeper 就能正常服務(wù)）。
為了保證高可用，最好是以集群形態(tài)來部署 ZooKeeper，這樣只要集群中大部分機(jī)器是可用的（能夠容忍一定的機(jī)器故障），那么 ZooKeeper 本身仍然是可用的。
ZooKeeper 將數(shù)據(jù)保存在內(nèi)存中，這也就保證了高吞吐量和低延遲（但是內(nèi)存限制了能夠存儲(chǔ)的容量不太大，此限制也是保持 Znode 中存儲(chǔ)的數(shù)據(jù)量較小的進(jìn)一步原因）。
ZooKeeper 是高性能的。在“讀”多于“寫”的應(yīng)用程序中尤其地高性能，因?yàn)?ldquo;寫”會(huì)導(dǎo)致所有的服務(wù)器間同步狀態(tài)。（“讀”多于“寫”是協(xié)調(diào)服務(wù)的典型場景。）
ZooKeeper 有臨時(shí)節(jié)點(diǎn)的概念。當(dāng)創(chuàng)建臨時(shí)節(jié)點(diǎn)的客戶端會(huì)話一直保持活動(dòng)，瞬時(shí)節(jié)點(diǎn)就一直存在。

而當(dāng)會(huì)話終結(jié)時(shí)，瞬時(shí)節(jié)點(diǎn)被刪除。持久節(jié)點(diǎn)是指一旦這個(gè) ZNode 被創(chuàng)建了，除非主動(dòng)進(jìn)行 ZNode 的移除操作，否則這個(gè) ZNode 將一直保存在 Zookeeper 上。

ZooKeeper 底層其實(shí)只提供了兩個(gè)功能：①管理（存儲(chǔ)、讀取）用戶程序提交的數(shù)據(jù)；②為用戶程序提交數(shù)據(jù)節(jié)點(diǎn)監(jiān)聽服務(wù)。

下面關(guān)于會(huì)話（Session）、 Znode、版本、Watcher、ACL 概念的總結(jié)都在《從 Paxos 到 ZooKeeper 》第四章第一節(jié)以及第七章第八節(jié)有提到，感興趣的可以看看！

會(huì)話（Session）

Session 指的是 ZooKeeper 服務(wù)器與客戶端會(huì)話。在 ZooKeeper 中，一個(gè)客戶端連接是指客戶端和服務(wù)器之間的一個(gè) TCP 長連接。

客戶端啟動(dòng)的時(shí)候，首先會(huì)與服務(wù)器建立一個(gè) TCP 連接，從第一次連接建立開始，客戶端會(huì)話的生命周期也開始了。

通過這個(gè)連接，客戶端能夠通過心跳檢測與服務(wù)器保持有效的會(huì)話，也能夠向 Zookeeper 服務(wù)器發(fā)送請(qǐng)求并接受響應(yīng)，同時(shí)還能夠通過該連接接收來自服務(wù)器的 Watch 事件通知。

Session 的 sessionTimeout 值用來設(shè)置一個(gè)客戶端會(huì)話的超時(shí)時(shí)間。

當(dāng)由于服務(wù)器壓力太大、網(wǎng)絡(luò)故障或是客戶端主動(dòng)斷開連接等各種原因?qū)е驴蛻舳诉B接斷開時(shí)，只要在 sessionTimeout 規(guī)定的時(shí)間內(nèi)能夠重新連接上集群中任意一臺(tái)服務(wù)器，那么之前創(chuàng)建的會(huì)話仍然有效。

在為客戶端創(chuàng)建會(huì)話之前，服務(wù)端首先會(huì)為每個(gè)客戶端都分配一個(gè) sessionID。

由于 sessionID 是 Zookeeper 會(huì)話的一個(gè)重要標(biāo)識(shí)，許多與會(huì)話相關(guān)的運(yùn)行機(jī)制都是基于這個(gè) sessionID 的。

因此，無論是哪臺(tái)服務(wù)器為客戶端分配的 sessionID，都務(wù)必保證全局唯一。

Znode

在談到分布式的時(shí)候，我們通常說的“節(jié)點(diǎn)"是指組成集群的每一臺(tái)機(jī)器。

然而，在 ZooKeeper 中，“節(jié)點(diǎn)"分為兩類：

第一類同樣是指構(gòu)成集群的機(jī)器，我們稱之為機(jī)器節(jié)點(diǎn)。
第二類則是指數(shù)據(jù)模型中的數(shù)據(jù)單元，我們稱之為數(shù)據(jù)節(jié)點(diǎn)一ZNode。

ZooKeeper 將所有數(shù)據(jù)存儲(chǔ)在內(nèi)存中，數(shù)據(jù)模型是一棵樹（Znode Tree)，由斜杠（/）的進(jìn)行分割的路徑，就是一個(gè) Znode，例如/foo/path1。每個(gè)上都會(huì)保存自己的數(shù)據(jù)內(nèi)容，同時(shí)還會(huì)保存一系列屬性信息。

在 Zookeeper 中，Node 可以分為持久節(jié)點(diǎn)和臨時(shí)節(jié)點(diǎn)兩類。所謂持久節(jié)點(diǎn)是指一旦這個(gè) ZNode 被創(chuàng)建了，除非主動(dòng)進(jìn)行 ZNode 的移除操作，否則這個(gè) ZNode 將一直保存在 ZooKeeper 上。

而臨時(shí)節(jié)點(diǎn)就不一樣了，它的生命周期和客戶端會(huì)話綁定，一旦客戶端會(huì)話失效，那么這個(gè)客戶端創(chuàng)建的所有臨時(shí)節(jié)點(diǎn)都會(huì)被移除。

另外，ZooKeeper 還允許用戶為每個(gè)節(jié)點(diǎn)添加一個(gè)特殊的屬性：SEQUENTIAL。

一旦節(jié)點(diǎn)被標(biāo)記上這個(gè)屬性，那么在這個(gè)節(jié)點(diǎn)被創(chuàng)建的時(shí)候，ZooKeeper 會(huì)自動(dòng)在其節(jié)點(diǎn)名后面追加上一個(gè)整型數(shù)字，這個(gè)整型數(shù)字是一個(gè)由父節(jié)點(diǎn)維護(hù)的自增數(shù)字。

版本

在前面我們已經(jīng)提到，Zookeeper 的每個(gè) ZNode 上都會(huì)存儲(chǔ)數(shù)據(jù)，對(duì)應(yīng)于每個(gè) ZNode，Zookeeper 都會(huì)為其維護(hù)一個(gè)叫作 Stat 的數(shù)據(jù)結(jié)構(gòu)。

Stat 中記錄了這個(gè) ZNode 的三個(gè)數(shù)據(jù)版本，分別是：

version（當(dāng)前 ZNode 的版本）
cversion（當(dāng)前 ZNode 子節(jié)點(diǎn)的版本）
aversion（當(dāng)前 ZNode 的 ACL 版本）

Watcher

Watcher（事件監(jiān)聽器），是 ZooKeeper 中的一個(gè)很重要的特性。

ZooKeeper 允許用戶在指定節(jié)點(diǎn)上注冊(cè)一些 Watcher，并且在一些特定事件觸發(fā)的時(shí)候，ZooKeeper 服務(wù)端會(huì)將事件通知到感興趣的客戶端上去，該機(jī)制是 ZooKeeper 實(shí)現(xiàn)分布式協(xié)調(diào)服務(wù)的重要特性。

ACL

ZooKeeper 采用 ACL（AccessControlLists）策略來進(jìn)行權(quán)限控制，類似于 UNIX 文件系統(tǒng)的權(quán)限控制。

ZooKeeper 定義了 5 種權(quán)限，如下圖：

其中尤其需要注意的是，CREATE 和 DELETE 這兩種權(quán)限都是針對(duì)子節(jié)點(diǎn)的權(quán)限控制。

ZooKeeper 特點(diǎn)

ZooKeeper 有哪些特點(diǎn)呢？具體如下：

順序一致性：從同一客戶端發(fā)起的事務(wù)請(qǐng)求，最終將會(huì)嚴(yán)格地按照順序被應(yīng)用到 ZooKeeper 中去。
原子性：所有事務(wù)請(qǐng)求的處理結(jié)果在整個(gè)集群中所有機(jī)器上的應(yīng)用情況是一致的，也就是說，要么整個(gè)集群中所有的機(jī)器都成功應(yīng)用了某一個(gè)事務(wù)，要么都沒有應(yīng)用。
單一系統(tǒng)映像：無論客戶端連到哪一個(gè) ZooKeeper 服務(wù)器上，其看到的服務(wù)端數(shù)據(jù)模型都是一致的。
可靠性：一旦一次更改請(qǐng)求被應(yīng)用，更改的結(jié)果就會(huì)被持久化，直到被下一次更改覆蓋。

ZooKeeper 設(shè)計(jì)目標(biāo)

簡單的數(shù)據(jù)模型

ZooKeeper 允許分布式進(jìn)程通過共享的層次結(jié)構(gòu)命名空間進(jìn)行相互協(xié)調(diào)，這與標(biāo)準(zhǔn)文件系統(tǒng)類似。

名稱空間由 ZooKeeper 中的數(shù)據(jù)寄存器組成，稱為 Znode，這些類似于文件和目錄。

與為存儲(chǔ)設(shè)計(jì)的典型文件系統(tǒng)不同，ZooKeeper 數(shù)據(jù)保存在內(nèi)存中，這意味著 ZooKeeper 可以實(shí)現(xiàn)高吞吐量和低延遲。

可構(gòu)建集群

為了保證高可用，最好是以集群形態(tài)來部署 ZooKeeper，這樣只要集群中大部分機(jī)器是可用的（能夠容忍一定的機(jī)器故障），那么 ZooKeeper 本身仍然是可用的。

客戶端在使用 ZooKeeper 時(shí)，需要知道集群機(jī)器列表，通過與集群中的某一臺(tái)機(jī)器建立 TCP 連接來使用服務(wù)。

客戶端使用這個(gè) TCP 鏈接來發(fā)送請(qǐng)求、獲取結(jié)果、獲取監(jiān)聽事件以及發(fā)送心跳包。如果這個(gè)連接異常斷開了，客戶端可以連接到另外的機(jī)器上。

ZooKeeper 官方提供的架構(gòu)圖：

上圖中每一個(gè) Server 代表一個(gè)安裝 ZooKeeper 服務(wù)的服務(wù)器。組成 ZooKeeper 服務(wù)的服務(wù)器都會(huì)在內(nèi)存中維護(hù)當(dāng)前的服務(wù)器狀態(tài)，并且每臺(tái)服務(wù)器之間都互相保持著通信。

集群間通過 Zab 協(xié)議（Zookeeper Atomic Broadcast）來保持?jǐn)?shù)據(jù)的一致性。

順序訪問

對(duì)于來自客戶端的每個(gè)更新請(qǐng)求，ZooKeeper 都會(huì)分配一個(gè)全局唯一的遞增編號(hào)。

這個(gè)編號(hào)反應(yīng)了所有事務(wù)操作的先后順序，應(yīng)用程序可以使用 ZooKeeper 這個(gè)特性來實(shí)現(xiàn)更高層次的同步原語。這個(gè)編號(hào)也叫做時(shí)間戳—zxid（ZooKeeper Transaction Id）。

高性能

ZooKeeper 是高性能的。在“讀”多于“寫”的應(yīng)用程序中尤其地高性能，因?yàn)?ldquo;寫”會(huì)導(dǎo)致所有的服務(wù)器間同步狀態(tài)。（“讀”多于“寫”是協(xié)調(diào)服務(wù)的典型場景。）

ZooKeeper 集群角色介紹

最典型集群模式：Master/Slave 模式（主備模式）。在這種模式中，通常 Master 服務(wù)器作為主服務(wù)器提供寫服務(wù)，其他的 Slave 服務(wù)器從服務(wù)器通過異步復(fù)制的方式獲取 Master 服務(wù)器最新的數(shù)據(jù)提供讀服務(wù)。

但是，在 ZooKeeper 中沒有選擇傳統(tǒng)的 Master/Slave 概念，而是引入了Leader、Follower 和 Observer 三種角色。

如下圖所示：

ZooKeeper 集群中的所有機(jī)器通過一個(gè) Leader 選舉過程來選定一臺(tái)稱為 “Leader” 的機(jī)器。

Leader 既可以為客戶端提供寫服務(wù)又能提供讀服務(wù)。除了 Leader 外，F(xiàn)ollower 和 Observer 都只能提供讀服務(wù)。

Follower 和 Observer 唯一的區(qū)別在于 Observer 機(jī)器不參與 Leader 的選舉過程，也不參與寫操作的“過半寫成功”策略，因此 Observer 機(jī)器可以在不影響寫性能的情況下提升集群的讀性能。

ZooKeeper & ZAB 協(xié)議 & Paxos 算法

ZAB 協(xié)議 & Paxos 算法

Paxos 算法可以說是 ZooKeeper 的靈魂了。但是，ZooKeeper 并沒有完全采用 Paxos 算法，而是使用 ZAB 協(xié)議作為其保證數(shù)據(jù)一致性的核心算法。

另外，在 ZooKeeper 的官方文檔中也指出，ZAB 協(xié)議并不像 Paxos 算法那樣，是一種通用的分布式一致性算法，它是一種特別為 ZooKeeper 設(shè)計(jì)的崩潰可恢復(fù)的原子消息廣播算法。

ZAB 協(xié)議介紹

ZAB（ZooKeeper Atomic Broadcast 原子廣播）協(xié)議是為分布式協(xié)調(diào)服務(wù) ZooKeeper 專門設(shè)計(jì)的一種支持崩潰恢復(fù)的原子廣播協(xié)議。

在 ZooKeeper 中，主要依賴 ZAB 協(xié)議來實(shí)現(xiàn)分布式數(shù)據(jù)一致性，基于該協(xié)議，ZooKeeper 實(shí)現(xiàn)了一種主備模式的系統(tǒng)架構(gòu)來保持集群中各個(gè)副本之間的數(shù)據(jù)一致性。

ZAB 協(xié)議兩種基本的模式

ZAB 協(xié)議包括兩種基本的模式，分別是崩潰恢復(fù)和消息廣播。

當(dāng)整個(gè)服務(wù)框架在啟動(dòng)過程中，或是當(dāng) Leader 服務(wù)器出現(xiàn)網(wǎng)絡(luò)中斷、崩潰退出與重啟等異常情況時(shí)，ZAB 協(xié)議就會(huì)進(jìn)入恢復(fù)模式并選舉產(chǎn)生新的 Leader 服務(wù)器。

當(dāng)選舉產(chǎn)生了新的 Leader 服務(wù)器，同時(shí)集群中已經(jīng)有過半的機(jī)器與該 Leader 服務(wù)器完成了狀態(tài)同步之后，ZAB 協(xié)議就會(huì)退出恢復(fù)模式。

其中，所謂的狀態(tài)同步是指數(shù)據(jù)同步，用來保證集群中存在過半的機(jī)器能夠和 Leader 服務(wù)器的數(shù)據(jù)狀態(tài)保持一致。

當(dāng)集群中已經(jīng)有過半的 Follower 服務(wù)器完成了和 Leader 服務(wù)器的狀態(tài)同步，那么整個(gè)服務(wù)框架就可以進(jìn)人消息廣播模式了。

當(dāng)一臺(tái)同樣遵守 ZAB 協(xié)議的服務(wù)器啟動(dòng)后加入到集群中時(shí)，如果此時(shí)集群中已經(jīng)存在一個(gè) Leader 服務(wù)器在負(fù)責(zé)進(jìn)行消息廣播。

那么新加入的服務(wù)器就會(huì)自覺地進(jìn)人數(shù)據(jù)恢復(fù)模式：找到 Leader 所在的服務(wù)器，并與其進(jìn)行數(shù)據(jù)同步，然后一起參與到消息廣播流程中去。

正如上文介紹中所說的，ZooKeeper 設(shè)計(jì)成只允許唯一的一個(gè) Leader 服務(wù)器來進(jìn)行事務(wù)請(qǐng)求的處理。

Leader 服務(wù)器在接收到客戶端的事務(wù)請(qǐng)求后，會(huì)生成對(duì)應(yīng)的事務(wù)提案并發(fā)起一輪廣播協(xié)議。

而如果集群中的其他機(jī)器接收到客戶端的事務(wù)請(qǐng)求，那么這些非 Leader 服務(wù)器會(huì)首先將這個(gè)事務(wù)請(qǐng)求轉(zhuǎn)發(fā)給 Leader 服務(wù)器。

關(guān)于 ZAB 協(xié)議 & Paxos 算法需要講和理解的東西太多了，推薦閱讀下面兩篇文章：