# 漫畫：什么是ZooKeeper？   **————— 第二天 —————**           ————————————        **Zookeeper的數據模型** Zookeeper的數據模型是什么樣子呢？它很像數據結構當中的樹，也很像文件系統的目錄。  樹是由節點所組成，Zookeeper的數據存儲也同樣是基于節點，這種節點叫做**Znode**。 但是，不同于樹的節點，Znode的引用方式是**路徑引用**，類似于文件路徑： / 動物 / 倉鼠 / 植物 / 荷花 這樣的層級結構，讓每一個Znode節點擁有唯一的路徑，就像命名空間一樣對不同信息作出清晰的隔離。    **data：** Znode存儲的數據信息。 **ACL：** 記錄Znode的訪問權限，即哪些人或哪些IP可以訪問本節點。 **stat：** 包含Znode的各種元數據，比如事務ID、版本號、時間戳、大小等等。 **child：** 當前節點的子節點引用，類似于二叉樹的左孩子右孩子。 這里需要注意一點，Zookeeper是為讀多寫少的場景所設計。Znode并不是用來存儲大規模業務數據，而是用于存儲少量的狀態和配置信息，**每個節點的數據最大不能超過1MB**。   ******Zookeeper的基本操作和事件通知****** Zookeeper包含了哪些基本操作呢？這里列舉出比較常用的API： **create** 創建節點 **delete** 刪除節點 **exists** 判斷節點是否存在 **getData** 獲得一個節點的數據 **setData** 設置一個節點的數據 **getChildren** 獲取節點下的所有子節點 這其中，exists，getData，getChildren屬于讀操作。Zookeeper客戶端在請求讀操作的時候，可以選擇是否設置**Watch**。 Watch是什么意思呢？ 我們可以理解成是注冊在特定Znode上的觸發器。當這個Znode發生改變，也就是調用了create，delete，setData方法的時候，將會觸發Znode上注冊的對應事件，請求Watch的客戶端會接收到**異步通知**。 具體交互過程如下： 1.客戶端調用getData方法，watch參數是true。服務端接到請求，返回節點數據，并且在對應的哈希表里插入被Watch的Znode路徑，以及Watcher列表。  2.當被Watch的Znode已刪除，服務端會查找哈希表，找到該Znode對應的所有Watcher，異步通知客戶端，并且刪除哈希表中對應的Key-Value。  ****Zookeeper的一致性****   Zookeeper的集群長成什么樣呢？就像下圖這樣：  Zookeeper Service集群是一主多從結構。 在更新數據時，首先更新到主節點（這里的節點是指服務器，不是Znode），再同步到從節點。 在讀取數據時，直接讀取任意從節點。 為了保證主從節點的數據一致性，Zookeeper采用了**ZAB協議**，這種協議非常類似于一致性算法**Paxos**和**Raft**。   在學習ZAB之前，我們需要首先了解ZAB協議所定義的三種節點狀態： **Looking**：選舉狀態。 **Following**：Follower節點（從節點）所處的狀態。 **Leading**：Leader節點（主節點）所處狀態。 我們還需要知道**最大ZXID**的概念： 最大ZXID也就是節點本地的最新事務編號，包含**epoch**和計數兩部分。epoch是紀元的意思，相當于Raft算法選主時候的term。 假如Zookeeper當前的主節點掛掉了，集群會進行**崩潰恢復**。ZAB的崩潰恢復分成三個階段： **1.Leader election** 選舉階段，此時集群中的節點處于Looking狀態。它們會各自向其他節點發起投票，投票當中包含自己的服務器ID和最新事務ID（ZXID）。  接下來，節點會用自身的ZXID和從其他節點接收到的ZXID做比較，如果發現別人家的ZXID比自己大，也就是數據比自己新，那么就重新發起投票，投票給目前已知最大的ZXID所屬節點。  每次投票后，服務器都會統計投票數量，判斷是否有某個節點得到半數以上的投票。如果存在這樣的節點，該節點將會成為準Leader，狀態變為Leading。其他節點的狀態變為Following。  這就相當于，一群武林高手經過激烈的競爭，選出了武林盟主。 **2.Discovery** 發現階段，用于在從節點中發現最新的ZXID和事務日志。或許有人會問：既然Leader被選為主節點，已經是集群里數據最新的了，為什么還要從節點中尋找最新事務呢？ 這是為了防止某些意外情況，比如因網絡原因在上一階段產生多個Leader的情況。 所以這一階段，Leader集思廣益，接收所有Follower發來各自的最新epoch值。Leader從中選出最大的epoch，基于此值加1，生成新的epoch分發給各個Follower。 各個Follower收到全新的epoch后，返回ACK給Leader，帶上各自最大的ZXID和歷史事務日志。Leader選出最大的ZXID，并更新自身歷史日志。 **3.Synchronization** 同步階段，把Leader剛才收集得到的最新歷史事務日志，同步給集群中所有的Follower。只有當半數Follower同步成功，這個準Leader才能成為正式的Leader。 自此，故障恢復正式完成。   什么是**Broadcast**呢？簡單來說，就是Zookeeper常規情況下更新數據的時候，由Leader廣播到所有的Follower。其過程如下： 1.客戶端發出寫入數據請求給任意Follower。 2.Follower把寫入數據請求轉發給Leader。 3.Leader采用二階段提交方式，先發送Propose廣播給Follower。 4.Follower接到Propose消息，寫入日志成功后，返回ACK消息給Leader。 5.Leader接到半數以上ACK消息，返回成功給客戶端，并且廣播Commit請求給Follower。  Zab協議既不是強一致性，也不是弱一致性，而是處于兩者之間的**單調一致性**。它依靠事務ID和版本號，保證了數據的更新和讀取是有序的。 ********Zookeeper的應用********   **1.分布式鎖** 這是雅虎研究員設計Zookeeper的初衷。利用Zookeeper的臨時順序節點，可以輕松實現分布式鎖。 **2.服務注冊和發現** 利用Znode和Watcher，可以實現分布式服務的注冊和發現。最著名的應用就是阿里的分布式RPC框架Dubbo。 **3.共享配置和狀態信息** Redis的分布式解決方案Codis，就利用了Zookeeper來存放數據路由表和 codis-proxy 節點的元信息。同時 codis-config 發起的命令都會通過 ZooKeeper 同步到各個存活的 codis-proxy。 此外，Kafka、HBase、Hadoop，也都依靠Zookeeper同步節點信息，實現高可用。   **幾點補充：** 1.ZAB協議相對比較復雜，小灰對此也只是淺層次的理解，有興趣的小伙伴們可以去官方社區進行進一步學習。 **2.本漫畫純屬娛樂，還請大家盡量珍惜當下的工作，切勿模仿小灰的行為哦。** 轉載至：[https://juejin.im/post/5b037d5c518825426e024473](https://juejin.im/post/5b037d5c518825426e024473)