前言
相信大家對 ZooKeeper 應該不算陌生筒扒。但是你真的了解 ZooKeeper 是個什么東西嗎揽碘？如果別人/面試官讓你給他講講 ZooKeeper 是個什么東西浦徊，你能回答到什么地步呢？
我本人曾經(jīng)使用過 ZooKeeper 作為 Dubbo 的注冊中心掀宋，另外在搭建 solr 集群的時候深纲，我使用到了 ZooKeeper 作為 solr 集群的管理工具。前幾天布朦，總結(jié)項目經(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 的由來
下面這段內(nèi)容摘自《從Paxos到Zookeeper 》第四章第一節(jié)的某段內(nèi)容暖庄，推薦大家閱讀以下：
Zookeeper最早起源于雅虎研究院的一個研究小組。在當時楼肪，研究人員發(fā)現(xiàn)培廓，在雅虎內(nèi)部很多大型系統(tǒng)基本都需要依賴一個類似的系統(tǒng)來進行分布式協(xié)調(diào)，但是這些系統(tǒng)往往都存在分布式單點問題春叫。所以医舆，雅虎的開發(fā)人員就試圖開發(fā)一個通用的無單點問題的分布式協(xié)調(diào)框架，以便讓開發(fā)人員將精力集中在處理業(yè)務邏輯上象缀。
關于“ZooKeeper”這個項目的名字，其實也有一段趣聞爷速。在立項初期央星，考慮到之前內(nèi)部很多項目都是使用動物的名字來命名的（例如著名的Pig項目),雅虎的工程師希望給這個項目也取一個動物的名字。時任研究院的首席科學家RaghuRamakrishnan開玩笑地說：“在這樣下去惫东，我們這兒就變成動物園了莉给！”此話一出，大家紛紛表示就叫動物園管理員吧一一一因為各個以動物命名的分布式組件放在一起廉沮，雅虎的整個分布式系統(tǒng)看上去就像一個大型的動物園了颓遏，而Zookeeper正好要用來進行分布式環(huán)境的協(xié)調(diào)一一于是，Zookeeper的名字也就由此誕生了滞时。
1.1 ZooKeeper 概覽
ZooKeeper 是一個開源的分布式協(xié)調(diào)服務叁幢，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é)調(diào)/通知、集群管理颁井、Master 選舉厅贪、分布式鎖和分布式隊列等功能。
Zookeeper 一個最常用的使用場景就是用于擔任服務生產(chǎn)者和服務消費者的注冊中心雅宾。?服務生產(chǎn)者將自己提供的服務注冊到Zookeeper中心养涮，服務的消費者在進行服務調(diào)用的時候先到Zookeeper中查找服務，獲取到服務生產(chǎn)者的詳細信息之后眉抬，再去調(diào)用服務生產(chǎn)者的內(nèi)容與數(shù)據(jù)贯吓。如下圖所示，在 Dubbo架構中 Zookeeper 就擔任了注冊中心這一角色蜀变。
1.2 結(jié)合個人使用情況的講一下 ZooKeeper
在我自己做過的項目中悄谐，主要使用到了 ZooKeeper 作為 Dubbo 的注冊中心(Dubbo 官方推薦使用 ZooKeeper注冊中心)。另外在搭建 solr 集群的時候库北，我使用 ZooKeeper 作為 solr 集群的管理工具爬舰。這時，ZooKeeper 主要提供下面幾個功能：1寒瓦、集群管理：容錯情屹、負載均衡。2杂腰、配置文件的集中管理3垃你、集群的入口。
我個人覺得在使用 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末融。12341234
二 關于 ZooKeeper 的一些重要概念
2.1 重要概念總結(jié)
ZooKeeper 本身就是一個分布式程序（只要半數(shù)以上節(jié)點存活钧惧，ZooKeeper 就能正常服務）。
為了保證高可用勾习，最好是以集群形態(tài)來部署 ZooKeeper浓瞪，這樣只要集群中大部分機器是可用的（能夠容忍一定的機器故障），那么 ZooKeeper 本身仍然是可用的巧婶。
ZooKeeper 將數(shù)據(jù)保存在內(nèi)存中乾颁，這也就保證了 高吞吐量和低延遲（但是內(nèi)存限制了能夠存儲的容量不太大，此限制也是保持znode中存儲的數(shù)據(jù)量較小的進一步原因）艺栈。
ZooKeeper 是高性能的英岭。 在“讀”多于“寫”的應用程序中尤其地高性能，因為“寫”會導致所有的服務器間同步狀態(tài)湿右。（“讀”多于“寫”是協(xié)調(diào)服務的典型場景巴席。）
ZooKeeper有臨時節(jié)點的概念。 當創(chuàng)建臨時節(jié)點的客戶端會話一直保持活動诅需，瞬時節(jié)點就一直存在。而當會話終結(jié)時荧库，瞬時節(jié)點被刪除堰塌。持久節(jié)點是指一旦這個ZNode被創(chuàng)建了，除非主動進行ZNode的移除操作分衫，否則這個ZNode將一直保存在Zookeeper上场刑。
ZooKeeper 底層其實只提供了兩個功能：①管理（存儲、讀闰秸健）用戶程序提交的數(shù)據(jù)牵现；②為用戶程序提交數(shù)據(jù)節(jié)點監(jiān)聽服務。
下面關于會話（Session）邀桑、 Znode瞎疼、版本、Watcher壁畸、ACL概念的總結(jié)都在《從Paxos到Zookeeper 》第四章第一節(jié)以及第七章第八節(jié)有提到贼急，感興趣的可以看看！
2.2 會話（Session）
Session 指的是 ZooKeeper 服務器與客戶端會話捏萍。在 ZooKeeper 中太抓，一個客戶端連接是指客戶端和服務器之間的一個 TCP 長連接令杈。客戶端啟動的時候逗噩，首先會與服務器建立一個 TCP 連接跌榔，從第一次連接建立開始，客戶端會話的生命周期也開始了机打。通過這個連接，客戶端能夠通過心跳檢測與服務器保持有效的會話残邀，也能夠向Zookeeper服務器發(fā)送請求并接受響應，同時還能夠通過該連接接收來自服務器的Watch事件通知芥挣。?Session的sessionTimeout值用來設置一個客戶端會話的超時時間。當由于服務器壓力太大空免、網(wǎng)絡故障或是客戶端主動斷開連接等各種原因?qū)е驴蛻舳诉B接斷開時空另，只要在sessionTimeout規(guī)定的時間內(nèi)能夠重新連接上集群中任意一臺服務器，那么之前創(chuàng)建的會話仍然有效蹋砚。
在為客戶端創(chuàng)建會話之前扼菠，服務端首先會為每個客戶端都分配一個sessionID。由于 sessionID 是 Zookeeper 會話的一個重要標識坝咐，許多與會話相關的運行機制都是基于這個 sessionID 的循榆，因此，無論是哪臺服務器為客戶端分配的 sessionID墨坚，都務必保證全局唯一秧饮。
2.3 Znode
在談到分布式的時候，我們通常說的“節(jié)點"是指組成集群的每一臺機器泽篮。然而盗尸，在Zookeeper中，“節(jié)點"分為兩類帽撑，第一類同樣是指構成集群的機器泼各，我們稱之為機器節(jié)點；第二類則是指數(shù)據(jù)模型中的數(shù)據(jù)單元亏拉，我們稱之為數(shù)據(jù)節(jié)點一一ZNode历恐。
Zookeeper將所有數(shù)據(jù)存儲在內(nèi)存中，數(shù)據(jù)模型是一棵樹（Znode Tree)专筷，由斜杠（/）的進行分割的路徑弱贼，就是一個Znode，例如/foo/path1磷蛹。每個上都會保存自己的數(shù)據(jù)內(nèi)容吮旅，同時還會保存一系列屬性信息。
在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ù)字。
2.4 版本
在前面我們已經(jīng)提到懦胞，Zookeeper 的每個 ZNode 上都會存儲數(shù)據(jù)躏尉，對應于每個ZNode旧困，Zookeeper 都會為其維護一個叫作?Stat?的數(shù)據(jù)結(jié)構吼具，Stat中記錄了這個 ZNode 的三個數(shù)據(jù)版本拗盒，分別是version（當前ZNode的版本）陡蝇、cversion（當前ZNode子節(jié)點的版本）和 cversion（當前ZNode的ACL版本）哮肚。
2.5 Watcher
Watcher（事件監(jiān)聽器），是Zookeeper中的一個很重要的特性恼策。Zookeeper允許用戶在指定節(jié)點上注冊一些Watcher涣楷，并且在一些特定事件觸發(fā)的時候，ZooKeeper服務端會將事件通知到感興趣的客戶端上去狮斗，該機制是Zookeeper實現(xiàn)分布式協(xié)調(diào)服務的重要特性碳褒。
2.6 ACL
Zookeeper采用ACL（AccessControlLists）策略來進行權限控制，類似于 UNIX 文件系統(tǒng)的權限控制鞍爱。Zookeeper 定義了如下5種權限睹逃。
其中尤其需要注意的是沉填，CREATE和DELETE這兩種權限都是針對子節(jié)點的權限控制翼闹。
三 ZooKeeper 特點
順序一致性：?從同一客戶端發(fā)起的事務請求蒋纬，最終將會嚴格地按照順序被應用到 ZooKeeper 中去蜀备。
原子性：?所有事務請求的處理結(jié)果在整個集群中所有機器上的應用情況是一致的，也就是說输虱，要么整個集群中所有的機器都成功應用了某一個事務宪睹，要么都沒有應用蚕钦。
單一系統(tǒng)映像 ：?無論客戶端連到哪一個 ZooKeeper 服務器上嘶居，其看到的服務端數(shù)據(jù)模型都是一致的。
可靠性：?一旦一次更改請求被應用污茵，更改的結(jié)果就會被持久化葬项，直到被下一次更改覆蓋民珍。
四 ZooKeeper 設計目標
4.1 簡單的數(shù)據(jù)模型
ZooKeeper 允許分布式進程通過共享的層次結(jié)構命名空間進行相互協(xié)調(diào)，這與標準文件系統(tǒng)類似陋桂。 名稱空間由 ZooKeeper 中的數(shù)據(jù)寄存器組成 - 稱為znode嗜历，這些類似于文件和目錄梨州。 與為存儲設計的典型文件系統(tǒng)不同田轧，ZooKeeper數(shù)據(jù)保存在內(nèi)存中，這意味著ZooKeeper可以實現(xiàn)高吞吐量和低延遲每窖。
4.2 可構建集群
為了保證高可用窒典，最好是以集群形態(tài)來部署 ZooKeeper崇败，這樣只要集群中大部分機器是可用的（能夠容忍一定的機器故障）肩祥，那么zookeeper本身仍然是可用的混狠。?客戶端在使用 ZooKeeper 時将饺，需要知道集群機器列表，通過與集群中的某一臺機器建立 TCP 連接來使用服務刮吧，客戶端使用這個TCP鏈接來發(fā)送請求杀捻、獲取結(jié)果蚓庭、獲取監(jiān)聽事件以及發(fā)送心跳包器赞。如果這個連接異常斷開了，客戶端可以連接到另外的機器上请契。
ZooKeeper 官方提供的架構圖：
上圖中每一個Server代表一個安裝Zookeeper服務的服務器姚糊。組成 ZooKeeper 服務的服務器都會在內(nèi)存中維護當前的服務器狀態(tài)救恨，并且每臺服務器之間都互相保持著通信释树。集群間通過 Zab 協(xié)議（Zookeeper Atomic Broadcast）來保持數(shù)據(jù)的一致性。
4.3 順序訪問
對于來自客戶端的每個更新請求秸仙，ZooKeeper 都會分配一個全局唯一的遞增編號寂纪，這個編號反應了所有事務操作的先后順序赌结，應用程序可以使用 ZooKeeper 這個特性來實現(xiàn)更高層次的同步原語。?這個編號也叫做時間戳——zxid（Zookeeper Transaction Id）
4.4 高性能
ZooKeeper 是高性能的拟杉。 在“讀”多于“寫”的應用程序中尤其地高性能搬设，因為“寫”會導致所有的服務器間同步狀態(tài)。（“讀”多于“寫”是協(xié)調(diào)服務的典型場景拿穴。）
五 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算法
6.1 ZAB 協(xié)議&Paxos算法
Paxos 算法應該可以說是 ZooKeeper 的靈魂了。但是奴曙，ZooKeeper 并沒有完全采用 Paxos算法 草讶，而是使用 ZAB 協(xié)議作為其保證數(shù)據(jù)一致性的核心算法堕战。另外，在ZooKeeper的官方文檔中也指出薪介，ZAB協(xié)議并不像 Paxos 算法那樣越驻，是一種通用的分布式一致性算法缀旁，它是一種特別為Zookeeper設計的崩潰可恢復的原子消息廣播算法。
6.2 ZAB 協(xié)議介紹
ZAB（ZooKeeper Atomic Broadcast 原子廣播） 協(xié)議是為分布式協(xié)調(diào)服務 ZooKeeper 專門設計的一種支持崩潰恢復的原子廣播協(xié)議目木。 在 ZooKeeper 中嘶窄，主要依賴 ZAB 協(xié)議來實現(xiàn)分布式數(shù)據(jù)一致性距贷，基于該協(xié)議，ZooKeeper 實現(xiàn)了一種主備模式的系統(tǒng)架構來保持集群中各個副本之間的數(shù)據(jù)一致性忠蝗。
6.3 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服務器會首先將這個事務請求轉(zhuǎn)發(fā)給Leader服務器把将。
關于?ZAB 協(xié)議&Paxos算法?需要講和理解的東西太多了察蹲，說實話，筆主到現(xiàn)在不太清楚這倆兄弟的具體原理和實現(xiàn)過程宗收。推薦閱讀下面兩篇文章：
關于如何使用 zookeeper 實現(xiàn)分布式鎖混稽，可以查看下面這篇文章：
六 總結(jié)
通過閱讀本文膳叨，想必大家已從?①ZooKeeper的由來。?->?②ZooKeeper 到底是什么 诡挂。->?③ ZooKeeper 的一些重要概念（會話（Session）璃俗、 Znode城豁、版本唱星、Watcher、ACL）->?④ZooKeeper 的特點攒盈。?->?⑤ZooKeeper 的設計目標哎榴。->?⑥ ZooKeeper 集群角色介紹?（Leader型豁、Follower 和 Observer 三種角色）->?⑦ZooKeeper &ZAB 協(xié)議&Paxos算法。?這七點了解了 ZooKeeper 尚蝌。
