點關注脉顿，不迷路；持續(xù)更新Java架構相關技術及資訊熱文５懔取０薄！
我本人曾經(jīng)使用過 ZooKeeper 作為 Dubbo 的注冊中心敢辩，另外在搭建 Solr 集群的時候蔽莱，我使用到了 ZooKeeper 作為 Solr 集群的管理工具。
前幾天戚长，總結項目經(jīng)驗的時候盗冷，我突然問自己 ZooKeeper 到底是個什么東西？
想了半天同廉，腦海中只是簡單的能浮現(xiàn)出幾句話：
- Zookeeper 可以被用作注冊中心仪糖。
- Zookeeper 是 Hadoop 生態(tài)系統(tǒng)的一員。
- 構建 Zookeeper 集群的時候迫肖，使用的服務器最好是奇數(shù)臺锅劝。
可見，我對于 Zookeeper 的理解僅僅是停留在了表面咒程。所以鸠天，通過本文，希望帶大家稍微詳細的了解一下 ZooKeeper 帐姻。
如果沒有學過 ZooKeeper稠集，那么本文將會是你進入 ZooKeeper 大門的墊腳磚；如果你已經(jīng)接觸過 ZooKeeper 饥瓷，那么本文將帶你回顧一下 ZooKeeper 的一些基礎概念剥纷。
最后，本文只涉及 ZooKeeper 的一些概念呢铆，并不涉及 ZooKeeper 的使用以及 ZooKeeper 集群的搭建晦鞋。
網(wǎng)上有介紹 ZooKeeper 的使用以及搭建 ZooKeeper 集群的文章，大家有需要可以自行查閱棺克。
一悠垛、什么是 ZooKeeper
Ⅰ.ZooKeeper 的由來
下面這段內容摘自《從 Paxos 到 ZooKeeper 》第四章第一節(jié)的某段內容，推薦大家閱讀一下：
Zookeeper 最早起源于雅虎研究院的一個研究小組娜谊。在當時确买，研究人員發(fā)現(xiàn)，在雅虎內部很多大型系統(tǒng)基本都需要依賴一個類似的系統(tǒng)來進行分布式協(xié)調纱皆，但是這些系統(tǒng)往往都存在分布式單點問題湾趾。
所以芭商，雅虎的開發(fā)人員就試圖開發(fā)一個通用的無單點問題的分布式協(xié)調框架，以便讓開發(fā)人員將精力集中在處理業(yè)務邏輯上搀缠。
關于“ZooKeeper”這個項目的名字铛楣，其實也有一段趣聞。在立項初期艺普，考慮到之前內部很多項目都是使用動物的名字來命名的（例如著名的Pig項目)簸州，雅虎的工程師希望給這個項目也取一個動物的名字。
時任研究院的首席科學家 Raghu Ramakrishnan 開玩笑地說：“在這樣下去衷敌，我們這兒就變成動物園了勿侯！”
此話一出，大家紛紛表示就叫動物園管理員吧缴罗，因為各個以動物命名的分布式組件放在一起，雅虎的整個分布式系統(tǒng)看上去就像一個大型的動物園了祭埂。
而 Zookeeper 正好要用來進行分布式環(huán)境的協(xié)調面氓，于是，Zookeeper 的名字也就由此誕生了蛆橡。
Ⅱ.ZooKeeper 概覽
ZooKeeper 是一個開源的分布式協(xié)調服務舌界，ZooKeeper 框架最初是在“Yahoo!"上構建的，用于以簡單而穩(wěn)健的方式訪問他們的應用程序泰演。
后來呻拌，Apache ZooKeeper 成為 Hadoop，HBase 和其他分布式框架使用的有組織服務的標準睦焕。
例如藐握，Apache HBase 使用 ZooKeeper 跟蹤分布式數(shù)據(jù)的狀態(tài)。
ZooKeeper 的設計目標是將那些復雜且容易出錯的分布式一致性服務封裝起來垃喊，構成一個高效可靠的原語集猾普，并以一系列簡單易用的接口提供給用戶使用。
原語： 操作系統(tǒng)或計算機網(wǎng)絡用語范疇本谜。它是由若干條指令組成的初家，用于完成一定功能的一個過程。具有不可分割性乌助，即原語的執(zhí)行必須是連續(xù)的溜在，在執(zhí)行過程中不允許被中斷。
ZooKeeper 是一個典型的分布式數(shù)據(jù)一致性解決方案他托，分布式應用程序可以基于 ZooKeeper 實現(xiàn)諸如數(shù)據(jù)發(fā)布/訂閱掖肋、負載均衡、命名服務上祈、分布式協(xié)調/通知培遵、集群管理浙芙、Master 選舉、分布式鎖和分布式隊列等功能籽腕。
ZooKeeper 一個最常用的使用場景就是用于擔任服務生產(chǎn)者和服務消費者的注冊中心嗡呼。
服務生產(chǎn)者將自己提供的服務注冊到 ZooKeeper 中心，服務的消費者在進行服務調用的時候先到 ZooKeeper 中查找服務皇耗，獲取到服務生產(chǎn)者的詳細信息之后南窗，再去調用服務生產(chǎn)者的內容與數(shù)據(jù)。
如下圖所示郎楼，在 Dubbo 架構中 ZooKeeper 就擔任了注冊中心這一角色万伤。
Ⅲ.結合個人使用講一下 ZooKeeper
在我自己做過的項目中，主要使用到了 ZooKeeper 作為 Dubbo 的注冊中心(Dubbo 官方推薦使用 ZooKeeper 注冊中心)呜袁。
另外在搭建 Solr 集群的時候敌买，我使用 ZooKeeper 作為 Solr 集群的管理工具。
這時阶界，ZooKeeper 主要提供下面幾個功能：
- 集群管理：容錯虹钮、負載均衡。
- 配置文件的集中管理膘融。
- 集群的入口芙粱。
我個人覺得在使用 ZooKeeper 的時候，最好是使用集群版的 ZooKeeper 而不是單機版的氧映。
官網(wǎng)給出的架構圖就描述的是一個集群版的 ZooKeeper 春畔。通常 3 臺服務器就可以構成一個 ZooKeeper 集群了。
為什么最好使用奇數(shù)臺服務器構成 ZooKeeper 集群岛都？
我們知道在 ZooKeeper 中 Leader 選舉算法采用了 Zab 協(xié)議律姨。Zab 核心思想是當多數(shù) Server 寫成功，則任務數(shù)據(jù)寫成功：
- 如果有 3 個 Server疗绣，則最多允許 1 個 Server 掛掉线召。
- 如果有 4 個 Server，則同樣最多允許 1 個 Server 掛掉多矮。
既然 3 個或者 4 個 Server缓淹，同樣最多允許 1 個 Server 掛掉，那么它們的可靠性是一樣的塔逃。
所以選擇奇數(shù)個 ZooKeeper Server 即可讯壶，這里選擇 3 個 Server。
二湾盗、關于 ZooKeeper 的一些重要概念
Ⅰ.重要概念總結
關于 ZooKeeper 的一些重要概念：
- ZooKeeper 本身就是一個分布式程序（只要半數(shù)以上節(jié)點存活伏蚊，ZooKeeper 就能正常服務）。
- 為了保證高可用格粪，最好是以集群形態(tài)來部署 ZooKeeper躏吊，這樣只要集群中大部分機器是可用的（能夠容忍一定的機器故障）氛改，那么 ZooKeeper 本身仍然是可用的。
- ZooKeeper 將數(shù)據(jù)保存在內存中比伏，這也就保證了 高吞吐量和低延遲（但是內存限制了能夠存儲的容量不太大胜卤，此限制也是保持 Znode 中存儲的數(shù)據(jù)量較小的進一步原因）。
- ZooKeeper 是高性能的赁项。在“讀”多于“寫”的應用程序中尤其地高性能葛躏，因為“寫”會導致所有的服務器間同步狀態(tài)。（“讀”多于“寫”是協(xié)調服務的典型場景悠菜。）
- ZooKeeper 有臨時節(jié)點的概念舰攒。當創(chuàng)建臨時節(jié)點的客戶端會話一直保持活動嗜诀，瞬時節(jié)點就一直存在勤众。
- 而當會話終結時，瞬時節(jié)點被刪除萄喳。持久節(jié)點是指一旦這個 ZNode 被創(chuàng)建了篙顺，除非主動進行 ZNode 的移除操作偶芍，否則這個 ZNode 將一直保存在 Zookeeper 上。
- ZooKeeper 底層其實只提供了兩個功能：①管理（存儲德玫、讀取）用戶程序提交的數(shù)據(jù)椎麦；②為用戶程序提交數(shù)據(jù)節(jié)點監(jiān)聽服務宰僧。
下面關于會話（Session）、 Znode观挎、版本琴儿、Watcher、ACL 概念的總結都在《從 Paxos 到 ZooKeeper 》第四章第一節(jié)以及第七章第八節(jié)有提到嘁捷，感興趣的可以看看造成！
Ⅱ.會話（Session）
Session 指的是 ZooKeeper 服務器與客戶端會話。在 ZooKeeper 中雄嚣，一個客戶端連接是指客戶端和服務器之間的一個 TCP 長連接晒屎。
客戶端啟動的時候，首先會與服務器建立一個 TCP 連接缓升，從第一次連接建立開始鼓鲁，客戶端會話的生命周期也開始了。
通過這個連接港谊，客戶端能夠通過心跳檢測與服務器保持有效的會話骇吭，也能夠向 Zookeeper 服務器發(fā)送請求并接受響應，同時還能夠通過該連接接收來自服務器的 Watch 事件通知歧寺。
Session 的 sessionTimeout 值用來設置一個客戶端會話的超時時間燥狰。
當由于服務器壓力太大棘脐、網(wǎng)絡故障或是客戶端主動斷開連接等各種原因導致客戶端連接斷開時，只要在 sessionTimeout 規(guī)定的時間內能夠重新連接上集群中任意一臺服務器龙致，那么之前創(chuàng)建的會話仍然有效蛀缝。
在為客戶端創(chuàng)建會話之前，服務端首先會為每個客戶端都分配一個 sessionID净当。
由于 sessionID 是 Zookeeper 會話的一個重要標識内斯，許多與會話相關的運行機制都是基于這個 sessionID 的。
因此像啼，無論是哪臺服務器為客戶端分配的 sessionID俘闯，都務必保證全局唯一。
Ⅲ.Znode
在談到分布式的時候忽冻，我們通常說的“節(jié)點"是指組成集群的每一臺機器真朗。
然而，在 ZooKeeper 中僧诚，“節(jié)點"分為兩類：
- 第一類同樣是指構成集群的機器遮婶，我們稱之為機器節(jié)點。
- 第二類則是指數(shù)據(jù)模型中的數(shù)據(jù)單元湖笨，我們稱之為數(shù)據(jù)節(jié)點一ZNode旗扑。
ZooKeeper 將所有數(shù)據(jù)存儲在內存中，數(shù)據(jù)模型是一棵樹（Znode Tree)慈省，由斜杠（/）的進行分割的路徑臀防，就是一個 Znode，例如/foo/path1边败。每個上都會保存自己的數(shù)據(jù)內容袱衷，同時還會保存一系列屬性信息。
在 Zookeeper 中笑窜，Node 可以分為持久節(jié)點和臨時節(jié)點兩類致燥。所謂持久節(jié)點是指一旦這個 ZNode 被創(chuàng)建了，除非主動進行 ZNode 的移除操作排截，否則這個 ZNode 將一直保存在 ZooKeeper 上嫌蚤。
而臨時節(jié)點就不一樣了，它的生命周期和客戶端會話綁定匾寝，一旦客戶端會話失效搬葬，那么這個客戶端創(chuàng)建的所有臨時節(jié)點都會被移除。
另外艳悔，ZooKeeper 還允許用戶為每個節(jié)點添加一個特殊的屬性：SEQUENTIAL急凰。
一旦節(jié)點被標記上這個屬性，那么在這個節(jié)點被創(chuàng)建的時候，ZooKeeper 會自動在其節(jié)點名后面追加上一個整型數(shù)字抡锈，這個整型數(shù)字是一個由父節(jié)點維護的自增數(shù)字疾忍。
Ⅳ.版本
在前面我們已經(jīng)提到，Zookeeper 的每個 ZNode 上都會存儲數(shù)據(jù)床三，對應于每個 ZNode一罩，Zookeeper 都會為其維護一個叫作 Stat 的數(shù)據(jù)結構。
Stat 中記錄了這個 ZNode 的三個數(shù)據(jù)版本撇簿，分別是：
- version（當前 ZNode 的版本）
- cversion（當前 ZNode 子節(jié)點的版本）
- aversion（當前 ZNode 的 ACL 版本）
Ⅴ.Watcher
Watcher（事件監(jiān)聽器）聂渊，是 ZooKeeper 中的一個很重要的特性。
ZooKeeper 允許用戶在指定節(jié)點上注冊一些 Watcher四瘫，并且在一些特定事件觸發(fā)的時候汉嗽，ZooKeeper 服務端會將事件通知到感興趣的客戶端上去，該機制是 ZooKeeper 實現(xiàn)分布式協(xié)調服務的重要特性找蜜。
Ⅵ.ACL
ZooKeeper 采用 ACL（AccessControlLists）策略來進行權限控制饼暑，類似于 UNIX 文件系統(tǒng)的權限控制。
ZooKeeper 定義了 5 種權限洗做，如下圖：
其中尤其需要注意的是弓叛，CREATE 和 DELETE 這兩種權限都是針對子節(jié)點的權限控制。
三诚纸、ZooKeeper 特點
ZooKeeper 有哪些特點呢撰筷？具體如下：
- 順序一致性：從同一客戶端發(fā)起的事務請求，最終將會嚴格地按照順序被應用到 ZooKeeper 中去畦徘。
- 原子性：所有事務請求的處理結果在整個集群中所有機器上的應用情況是一致的闭专，也就是說，要么整個集群中所有的機器都成功應用了某一個事務旧烧，要么都沒有應用。
- 單一系統(tǒng)映像：無論客戶端連到哪一個 ZooKeeper 服務器上画髓，其看到的服務端數(shù)據(jù)模型都是一致的掘剪。
- 可靠性：一旦一次更改請求被應用，更改的結果就會被持久化奈虾，直到被下一次更改覆蓋夺谁。
四、ZooKeeper 設計目標
Ⅰ.簡單的數(shù)據(jù)模型
ZooKeeper 允許分布式進程通過共享的層次結構命名空間進行相互協(xié)調肉微，這與標準文件系統(tǒng)類似匾鸥。
名稱空間由 ZooKeeper 中的數(shù)據(jù)寄存器組成，稱為 Znode碉纳，這些類似于文件和目錄勿负。
與為存儲設計的典型文件系統(tǒng)不同，ZooKeeper 數(shù)據(jù)保存在內存中劳曹，這意味著 ZooKeeper 可以實現(xiàn)高吞吐量和低延遲奴愉。
Ⅱ.可構建集群
為了保證高可用琅摩，最好是以集群形態(tài)來部署 ZooKeeper，這樣只要集群中大部分機器是可用的（能夠容忍一定的機器故障）锭硼，那么 ZooKeeper 本身仍然是可用的房资。
客戶端在使用 ZooKeeper 時，需要知道集群機器列表檀头，通過與集群中的某一臺機器建立 TCP 連接來使用服務轰异。
客戶端使用這個 TCP 鏈接來發(fā)送請求、獲取結果暑始、獲取監(jiān)聽事件以及發(fā)送心跳包搭独。如果這個連接異常斷開了，客戶端可以連接到另外的機器上蒋荚。
ZooKeeper 官方提供的架構圖：
上圖中每一個 Server 代表一個安裝 ZooKeeper 服務的服務器戳稽。組成 ZooKeeper 服務的服務器都會在內存中維護當前的服務器狀態(tài)，并且每臺服務器之間都互相保持著通信期升。
集群間通過 Zab 協(xié)議（Zookeeper Atomic Broadcast）來保持數(shù)據(jù)的一致性惊奇。
Ⅲ.順序訪問
對于來自客戶端的每個更新請求，ZooKeeper 都會分配一個全局唯一的遞增編號播赁。
這個編號反應了所有事務操作的先后順序颂郎，應用程序可以使用 ZooKeeper 這個特性來實現(xiàn)更高層次的同步原語。這個編號也叫做時間戳—zxid（ZooKeeper Transaction Id）容为。
Ⅳ.高性能
ZooKeeper 是高性能的乓序。在“讀”多于“寫”的應用程序中尤其地高性能，因為“寫”會導致所有的服務器間同步狀態(tài)坎背。（“讀”多于“寫”是協(xié)調服務的典型場景替劈。）
六、ZooKeeper 集群角色介紹
最典型集群模式：Master/Slave 模式（主備模式）得滤。在這種模式中陨献，通常 Master 服務器作為主服務器提供寫服務，其他的 Slave 服務器從服務器通過異步復制的方式獲取 Master 服務器最新的數(shù)據(jù)提供讀服務懂更。
但是眨业，在 ZooKeeper 中沒有選擇傳統(tǒng)的 Master/Slave 概念，而是引入了Leader沮协、Follower 和 Observer 三種角色龄捡。
如下圖所示：
ZooKeeper 集群中的所有機器通過一個 Leader 選舉過程來選定一臺稱為 “Leader” 的機器。
Leader 既可以為客戶端提供寫服務又能提供讀服務慷暂。除了 Leader 外聘殖，F(xiàn)ollower 和 Observer 都只能提供讀服務。
Follower 和 Observer 唯一的區(qū)別在于 Observer 機器不參與 Leader 的選舉過程，也不參與寫操作的“過半寫成功”策略就斤，因此 Observer 機器可以在不影響寫性能的情況下提升集群的讀性能悍募。
七、ZooKeeper & ZAB 協(xié)議 & Paxos 算法
Ⅰ.ZAB 協(xié)議 & Paxos 算法
Paxos 算法可以說是 ZooKeeper 的靈魂了洋机。但是坠宴，ZooKeeper 并沒有完全采用 Paxos 算法 ，而是使用 ZAB 協(xié)議作為其保證數(shù)據(jù)一致性的核心算法绷旗。
另外喜鼓，在 ZooKeeper 的官方文檔中也指出，ZAB 協(xié)議并不像 Paxos 算法那樣衔肢，是一種通用的分布式一致性算法庄岖，它是一種特別為 ZooKeeper 設計的崩潰可恢復的原子消息廣播算法。
Ⅱ.ZAB 協(xié)議介紹
ZAB（ZooKeeper Atomic Broadcast 原子廣播）協(xié)議是為分布式協(xié)調服務 ZooKeeper 專門設計的一種支持崩潰恢復的原子廣播協(xié)議角骤。
在 ZooKeeper 中隅忿，主要依賴 ZAB 協(xié)議來實現(xiàn)分布式數(shù)據(jù)一致性，基于該協(xié)議邦尊，ZooKeeper 實現(xiàn)了一種主備模式的系統(tǒng)架構來保持集群中各個副本之間的數(shù)據(jù)一致性背桐。
Ⅲ.ZAB 協(xié)議兩種基本的模式
ZAB 協(xié)議包括兩種基本的模式，分別是崩潰恢復和消息廣播蝉揍。
當整個服務框架在啟動過程中链峭，或是當 Leader 服務器出現(xiàn)網(wǎng)絡中斷、崩潰退出與重啟等異常情況時又沾，ZAB 協(xié)議就會進入恢復模式并選舉產(chǎn)生新的 Leader 服務器弊仪。
當選舉產(chǎn)生了新的 Leader 服務器，同時集群中已經(jīng)有過半的機器與該 Leader 服務器完成了狀態(tài)同步之后杖刷，ZAB 協(xié)議就會退出恢復模式励饵。
其中，所謂的狀態(tài)同步是指數(shù)據(jù)同步滑燃，用來保證集群中存在過半的機器能夠和 Leader 服務器的數(shù)據(jù)狀態(tài)保持一致曲横。
當集群中已經(jīng)有過半的 Follower 服務器完成了和 Leader 服務器的狀態(tài)同步，那么整個服務框架就可以進人消息廣播模式了不瓶。
當一臺同樣遵守 ZAB 協(xié)議的服務器啟動后加入到集群中時，如果此時集群中已經(jīng)存在一個 Leader 服務器在負責進行消息廣播灾杰。
那么新加入的服務器就會自覺地進人數(shù)據(jù)恢復模式：找到 Leader 所在的服務器蚊丐，并與其進行數(shù)據(jù)同步，然后一起參與到消息廣播流程中去艳吠。
正如上文介紹中所說的麦备，ZooKeeper 設計成只允許唯一的一個 Leader 服務器來進行事務請求的處理。
Leader 服務器在接收到客戶端的事務請求后，會生成對應的事務提案并發(fā)起一輪廣播協(xié)議凛篙。
而如果集群中的其他機器接收到客戶端的事務請求黍匾，那么這些非 Leader 服務器會首先將這個事務請求轉發(fā)給 Leader 服務器。
八呛梆、總結
通過閱讀本文锐涯，想必大家已從以下這七點了解了 ZooKeeper：
- ZooKeeper 的由來
- ZooKeeper 到底是什么
- ZooKeeper 的一些重要概念（會話（Session）、Znode填物、版本纹腌、Watcher、ACL）
- ZooKeeper 的特點
- ZooKeeper 的設計目標
- ZooKeeper 集群角色介紹（Leader滞磺、Follower 和 Observer 三種角色）
- ZooKeeper & ZAB 協(xié)議 & Paxos 算法
寫在最后
免費Java高級資料需要自己領壬怼：涵蓋了高可用,高并發(fā),高性能及分布式,Jvm性能調
優(yōu),MyBatis,Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料。
傳送門:https://shimo.im/docs/f2ajdNJBQJItSobT/
比你優(yōu)秀的對手在學習击困，你的仇人在磨刀涎劈，你的閨蜜在減肥，隔壁老王在練腰阅茶， 我們必須不斷學習蛛枚，否則我們將被學習者超越！
趁年輕目派，使勁拼坤候，給未來的自己一個交代！
