摘要：的設計目標是將那些復雜且容易出錯的分布式一致性服務封裝起來，構成一個高效可靠的原語集，并以一系列簡單易用的接口提供給用戶使用。具有不可分割性即原語的執行必須是連續的，在執行過程中不允許被中斷。

該文已加入開源文檔：JavaGuide（一份涵蓋大部分Java程序員所需要掌握的核心知識）。地址:https://github.com/Snailclimb...

相信大家對 ZooKeeper 應該不算陌生。但是你真的了解 ZooKeeper 是個什么東西嗎？如果別人/面試官讓你給他講講 ZooKeeper 是個什么東西，你能回答到什么地步呢？

我本人曾經使用過 ZooKeeper 作為 Dubbo 的注冊中心，另外在搭建 solr 集群的時候，我使用到了 ZooKeeper 作為 solr 集群的管理工具。前幾天，總結項目經驗的時候，我突然問自己 ZooKeeper 到底是個什么東西？想了半天，腦海中只是簡單的能浮現出幾句話：“①Zookeeper 可以被用作注冊中心。 ②Zookeeper 是 Hadoop 生態系統的一員；③構建 Zookeeper 集群的時候，使用的服務器最好是奇數臺。” 可見，我對于 Zookeeper 的理解僅僅是停留在了表面。

所以，通過本文，希望帶大家稍微詳細的了解一下 ZooKeeper 。如果沒有學過 ZooKeeper ，那么本文將會是你進入 ZooKeeper 大門的墊腳磚。如果你已經接觸過 ZooKeeper ，那么本文將帶你回顧一下 ZooKeeper 的一些基礎概念。

最后，本文只涉及 ZooKeeper 的一些概念，并不涉及 ZooKeeper 的使用以及 ZooKeeper 集群的搭建。 網上有介紹 ZooKeeper 的使用以及搭建 ZooKeeper 集群的文章，大家有需要可以自行查閱。

下面這段內容摘自《從Paxos到Zookeeper 》第四章第一節的某段內容，推薦大家閱讀以下：

Zookeeper最早起源于雅虎研究院的一個研究小組。在當時，研究人員發現，在雅虎內部很多大型系統基本都需要依賴一個類似的系統來進行分布式協調，但是這些系統往往都存在分布式單點問題。所以，雅虎的開發人員就試圖開發一個通用的無單點問題的分布式協調框架，以便讓開發人員將精力集中在處理業務邏輯上。
關于“ZooKeeper”這個項目的名字，其實也有一段趣聞。在立項初期，考慮到之前內部很多項目都是使用動物的名字來命名的（例如著名的Pig項目),雅虎的工程師希望給這個項目也取一個動物的名字。時任研究院的首席科學家RaghuRamakrishnan開玩笑地說：“在這樣下去，我們這兒就變成動物園了！”此話一出，大家紛紛表示就叫動物園管理員吧一一一因為各個以動物命名的分布式組件放在一起，雅虎的整個分布式系統看上去就像一個大型的動物園了，而Zookeeper正好要用來進行分布式環境的協調一一于是，Zookeeper的名字也就由此誕生了。

ZooKeeper 是一個開源的分布式協調服務，ZooKeeper框架最初是在“Yahoo!"上構建的，用于以簡單而穩健的方式訪問他們的應用程序。 后來，Apache ZooKeeper成為Hadoop，HBase和其他分布式框架使用的有組織服務的標準。 例如，Apache HBase使用ZooKeeper跟蹤分布式數據的狀態。ZooKeeper 的設計目標是將那些復雜且容易出錯的分布式一致性服務封裝起來，構成一個高效可靠的原語集，并以一系列簡單易用的接口提供給用戶使用。

原語： 操作系統或計算機網絡用語范疇。是由若干條指令組成的，用于完成一定功能的一個過程。具有不可分割性·即原語的執行必須是連續的，在執行過程中不允許被中斷。

ZooKeeper 是一個典型的分布式數據一致性解決方案，分布式應用程序可以基于 ZooKeeper 實現諸如數據發布/訂閱、負載均衡、命名服務、分布式協調/通知、集群管理、Master 選舉、分布式鎖和分布式隊列等功能。

Zookeeper 一個最常用的使用場景就是用于擔任服務生產者和服務消費者的注冊中心。 服務生產者將自己提供的服務注冊到Zookeeper中心，服務的消費者在進行服務調用的時候先到Zookeeper中查找服務，獲取到服務生產者的詳細信息之后，再去調用服務生產者的內容與數據。如下圖所示，在 Dubbo架構中 Zookeeper 就擔任了注冊中心這一角色。

在我自己做過的項目中，主要使用到了 ZooKeeper 作為 Dubbo 的注冊中心(Dubbo 官方推薦使用 ZooKeeper注冊中心)。另外在搭建 solr 集群的時候，我使用 ZooKeeper 作為 solr 集群的管理工具。這時，ZooKeeper 主要提供下面幾個功能：1、集群管理：容錯、負載均衡。2、配置文件的集中管理3、集群的入口。

我個人覺得在使用 ZooKeeper 的時候，最好是使用 集群版的 ZooKeeper 而不是單機版的。官網給出的架構圖就描述的是一個集群版的 ZooKeeper 。通常 3 臺服務器就可以構成一個 ZooKeeper 集群了。

為什么最好使用奇數臺服務器構成 ZooKeeper 集群？

我們知道在Zookeeper中 Leader 選舉算法采用了Zab協議。Zab核心思想是當多數 Server 寫成功，則任務數據寫成功。

①如果有3個Server，則最多允許1個Server 掛掉。

②如果有4個Server，則同樣最多允許1個Server掛掉。

既然3個或者4個Server，同樣最多允許1個Server掛掉，那么它們的可靠性是一樣的，所以選擇奇數個ZooKeeper Server即可，這里選擇3個Server。12341234

ZooKeeper 本身就是一個分布式程序（只要半數以上節點存活，ZooKeeper 就能正常服務）。

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

ZooKeeper 將數據保存在內存中，這也就保證了 高吞吐量和低延遲（但是內存限制了能夠存儲的容量不太大，此限制也是保持znode中存儲的數據量較小的進一步原因）。

ZooKeeper 是高性能的。 在“讀”多于“寫”的應用程序中尤其地高性能，因為“寫”會導致所有的服務器間同步狀態。（“讀”多于“寫”是協調服務的典型場景。）

ZooKeeper有臨時節點的概念。 當創建臨時節點的客戶端會話一直保持活動，瞬時節點就一直存在。而當會話終結時，瞬時節點被刪除。持久節點是指一旦這個ZNode被創建了，除非主動進行ZNode的移除操作，否則這個ZNode將一直保存在Zookeeper上。

ZooKeeper 底層其實只提供了兩個功能：①管理（存儲、讀取）用戶程序提交的數據；②為用戶程序提交數據節點監聽服務。

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

Session 指的是 ZooKeeper 服務器與客戶端會話。在 ZooKeeper 中，一個客戶端連接是指客戶端和服務器之間的一個 TCP 長連接。客戶端啟動的時候，首先會與服務器建立一個 TCP 連接，從第一次連接建立開始，客戶端會話的生命周期也開始了。通過這個連接，客戶端能夠通過心跳檢測與服務器保持有效的會話，也能夠向Zookeeper服務器發送請求并接受響應，同時還能夠通過該連接接收來自服務器的Watch事件通知。 Session的sessionTimeout值用來設置一個客戶端會話的超時時間。當由于服務器壓力太大、網絡故障或是客戶端主動斷開連接等各種原因導致客戶端連接斷開時，只要在sessionTimeout規定的時間內能夠重新連接上集群中任意一臺服務器，那么之前創建的會話仍然有效。

在為客戶端創建會話之前，服務端首先會為每個客戶端都分配一個sessionID。由于 sessionID 是 Zookeeper 會話的一個重要標識，許多與會話相關的運行機制都是基于這個 sessionID 的，因此，無論是哪臺服務器為客戶端分配的 sessionID，都務必保證全局唯一。

在談到分布式的時候，我們通常說的“節點"是指組成集群的每一臺機器。然而，在Zookeeper中，“節點"分為兩類，第一類同樣是指構成集群的機器，我們稱之為機器節點；第二類則是指數據模型中的數據單元，我們稱之為數據節點一一ZNode。

Zookeeper將所有數據存儲在內存中，數據模型是一棵樹（Znode Tree)，由斜杠（/）的進行分割的路徑，就是一個Znode，例如/foo/path1。每個上都會保存自己的數據內容，同時還會保存一系列屬性信息。

在Zookeeper中，node可以分為持久節點和臨時節點兩類。所謂持久節點是指一旦這個ZNode被創建了，除非主動進行ZNode的移除操作，否則這個ZNode將一直保存在Zookeeper上。而臨時節點就不一樣了，它的生命周期和客戶端會話綁定，一旦客戶端會話失效，那么這個客戶端創建的所有臨時節點都會被移除。另外，ZooKeeper還允許用戶為每個節點添加一個特殊的屬性：SEQUENTIAL.一旦節點被標記上這個屬性，那么在這個節點被創建的時候，Zookeeper會自動在其節點名后面追加上一個整型數字，這個整型數字是一個由父節點維護的自增數字。

在前面我們已經提到，Zookeeper 的每個 ZNode 上都會存儲數據，對應于每個ZNode，Zookeeper 都會為其維護一個叫作 Stat 的數據結構，Stat中記錄了這個 ZNode 的三個數據版本，分別是version（當前ZNode的版本）、cversion（當前ZNode子節點的版本）和 cversion（當前ZNode的ACL版本）。

Watcher（事件監聽器），是Zookeeper中的一個很重要的特性。Zookeeper允許用戶在指定節點上注冊一些Watcher，并且在一些特定事件觸發的時候，ZooKeeper服務端會將事件通知到感興趣的客戶端上去，該機制是Zookeeper實現分布式協調服務的重要特性。

Zookeeper采用ACL（AccessControlLists）策略來進行權限控制，類似于 UNIX 文件系統的權限控制。Zookeeper 定義了如下5種權限。

其中尤其需要注意的是，CREATE和DELETE這兩種權限都是針對子節點的權限控制。

順序一致性： 從同一客戶端發起的事務請求，最終將會嚴格地按照順序被應用到 ZooKeeper 中去。

原子性： 所有事務請求的處理結果在整個集群中所有機器上的應用情況是一致的，也就是說，要么整個集群中所有的機器都成功應用了某一個事務，要么都沒有應用。

單一系統映像 ： 無論客戶端連到哪一個 ZooKeeper 服務器上，其看到的服務端數據模型都是一致的。

可靠性： 一旦一次更改請求被應用，更改的結果就會被持久化，直到被下一次更改覆蓋。

ZooKeeper 允許分布式進程通過共享的層次結構命名空間進行相互協調，這與標準文件系統類似。 名稱空間由 ZooKeeper 中的數據寄存器組成 - 稱為znode，這些類似于文件和目錄。 與為存儲設計的典型文件系統不同，ZooKeeper數據保存在內存中，這意味著ZooKeeper可以實現高吞吐量和低延遲。

為了保證高可用，最好是以集群形態來部署 ZooKeeper，這樣只要集群中大部分機器是可用的（能夠容忍一定的機器故障），那么zookeeper本身仍然是可用的。 客戶端在使用 ZooKeeper 時，需要知道集群機器列表，通過與集群中的某一臺機器建立 TCP 連接來使用服務，客戶端使用這個TCP鏈接來發送請求、獲取結果、獲取監聽事件以及發送心跳包。如果這個連接異常斷開了，客戶端可以連接到另外的機器上。

ZooKeeper 官方提供的架構圖：

上圖中每一個Server代表一個安裝Zookeeper服務的服務器。組成 ZooKeeper 服務的服務器都會在內存中維護當前的服務器狀態，并且每臺服務器之間都互相保持著通信。集群間通過 Zab 協議（Zookeeper Atomic Broadcast）來保持數據的一致性。

對于來自客戶端的每個更新請求，ZooKeeper 都會分配一個全局唯一的遞增編號，這個編號反應了所有事務操作的先后順序，應用程序可以使用 ZooKeeper 這個特性來實現更高層次的同步原語。 這個編號也叫做時間戳——zxid（Zookeeper Transaction Id）

ZooKeeper 是高性能的。 在“讀”多于“寫”的應用程序中尤其地高性能，因為“寫”會導致所有的服務器間同步狀態。（“讀”多于“寫”是協調服務的典型場景。）

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

但是，在 ZooKeeper 中沒有選擇傳統的 Master/Slave 概念，而是引入了Leader、Follower 和 Observer 三種角色。如下圖所示

ZooKeeper 集群中的所有機器通過一個 Leader 選舉過程來選定一臺稱為 “Leader” 的機器，Leader 既可以為客戶端提供寫服務又能提供讀服務。除了 Leader 外，Follower 和 Observer 都只能提供讀服務。Follower 和 Observer 唯一的區別在于 Observer 機器不參與 Leader 的選舉過程，也不參與寫操作的“過半寫成功”策略，因此 Observer 機器可以在不影響寫性能的情況下提升集群的讀性能。

Paxos 算法應該可以說是 ZooKeeper 的靈魂了。但是，ZooKeeper 并沒有完全采用 Paxos算法 ，而是使用 ZAB 協議作為其保證數據一致性的核心算法。另外，在ZooKeeper的官方文檔中也指出，ZAB協議并不像 Paxos 算法那樣，是一種通用的分布式一致性算法，它是一種特別為Zookeeper設計的崩潰可恢復的原子消息廣播算法。

ZAB（ZooKeeper Atomic Broadcast 原子廣播） 協議是為分布式協調服務 ZooKeeper 專門設計的一種支持崩潰恢復的原子廣播協議。 在 ZooKeeper 中，主要依賴 ZAB 協議來實現分布式數據一致性，基于該協議，ZooKeeper 實現了一種主備模式的系統架構來保持集群中各個副本之間的數據一致性。

ZAB協議包括兩種基本的模式，分別是 崩潰恢復和消息廣播。當整個服務框架在啟動過程中，或是當 Leader 服務器出現網絡中斷、崩潰退出與重啟等異常情況時，ZAB 協議就會進人恢復模式并選舉產生新的Leader服務器。當選舉產生了新的 Leader 服務器，同時集群中已經有過半的機器與該Leader服務器完成了狀態同步之后，ZAB協議就會退出恢復模式。其中，所謂的狀態同步是指數據同步，用來保證集群中存在過半的機器能夠和Leader服務器的數據狀態保持一致。

當集群中已經有過半的Follower服務器完成了和Leader服務器的狀態同步，那么整個服務框架就可以進人消息廣播模式了。 當一臺同樣遵守ZAB協議的服務器啟動后加人到集群中時，如果此時集群中已經存在一個Leader服務器在負責進行消息廣播，那么新加人的服務器就會自覺地進人數據恢復模式：找到Leader所在的服務器，并與其進行數據同步，然后一起參與到消息廣播流程中去。正如上文介紹中所說的，ZooKeeper設計成只允許唯一的一個Leader服務器來進行事務請求的處理。Leader服務器在接收到客戶端的事務請求后，會生成對應的事務提案并發起一輪廣播協議；而如果集群中的其他機器接收到客戶端的事務請求，那么這些非Leader服務器會首先將這個事務請求轉發給Leader服務器。

關于 ZAB 協議&Paxos算法 需要講和理解的東西太多了，說實話，筆主到現在不太清楚這倆兄弟的具體原理和實現過程。推薦閱讀下面兩篇文章：

圖解 Paxos 一致性協議

Zookeeper ZAB 協議分析

關于如何使用 zookeeper 實現分布式鎖，可以查看下面這篇文章：

10分鐘看懂！基于Zookeeper的分布式鎖

通過閱讀本文，想必大家已從 ①ZooKeeper的由來。 -> ②ZooKeeper 到底是什么 。-> ③ ZooKeeper 的一些重要概念（會話（Session）、 Znode、版本、Watcher、ACL）-> ④ZooKeeper 的特點。 -> ⑤ZooKeeper 的設計目標。-> ⑥ ZooKeeper 集群角色介紹 （Leader、Follower 和 Observer 三種角色）-> ⑦ZooKeeper &ZAB 協議&Paxos算法。 這七點了解了 ZooKeeper 。

《從Paxos到Zookeeper 》

https://cwiki.apache.org/conf...

https://cwiki.apache.org/conf...

https://www.cnblogs.com/rapha...

https://zhuanlan.zhihu.com/p/...

你若盛開，清風自來。 歡迎關注我的微信公眾號：“Java面試通關手冊”，一個有溫度的微信公眾號。公眾號后臺回復關鍵字“1”，你可能看到想要的東西哦！