你平常使用zookeeper做什麼？是分散式協調服務、共享變數、協調鎖資源、還是提供名稱空間？

好了，接下來我們以提問的形式來開啟話題：

你知道zk能用來做什麼？

你知道zk的資料模型嗎？

你知道zk的資料結構嗎？

你會zk操作基本命令嗎？

這些命令是如何事件通知？

zk是如何保證一致性的？

你會用zk做什麼？

zk資料模型

瞭解一門技術，先知道它大致長得啥樣，這才好的去進一步認識。

zk的資料模型：

很像資料結構中的樹，也像檔案系統的目錄；

zk的資料儲存同樣基於節點，叫Znode；

但引用方式是：路徑引用，類似於檔案路徑，讓每一個節點擁有唯一的路徑

這裡講到了Znode （zk的節點）：

Znode資料結構

它的主要屬性有data、ACL、child、stat

data：Znode儲存的資料資訊。

ACL：記錄Znode的訪問許可權，即哪些人或哪些IP可以訪問本節點。

stat：包含Znode的各種元資料，比如事務ID、版本號、時間戳、大小等等。

child：當前節點的子節點引用，類似於二叉樹的左孩子右孩子。

注意：Zookeeper是為讀多寫少的場景所設計。Znode並不是用來儲存大規模業務資料，而是用於儲存少量的狀態和配置資訊，每個節點的資料最大不能超過1MB。

基本操作

Zookeeper包含了哪些基本操作呢？這裡列舉出比較常用的API：

create：建立節點

delete：刪除節點

exists：判斷節點是否存在

getData：獲得一個節點的資料

setData：設定一個節點的資料

getChildren：獲取節點下的所有子節點

exists，getData，getChildren屬於讀操作。Zookeeper客戶端在請求讀操作的時候，可以選擇是否設定Watch。

講到這，大家可能會聯想到我們平常使用的zkclient 這外掛，其實這裡面的命令都是通過if-else這樣判斷單獨呼叫遠端server的命令，目前博主對這個jar通訊方式還在研究，會單獨抽出時間整理一下。

zk客戶端的資料是如何與server資料保持一致，其中是離不開Watch動作的？

事件通知

Watch是什麼意思呢？

我們可以理解成是註冊在特定Znode上的觸發器。當這個Znode發生改變，也就是呼叫了create，delete，setData方法的時候，將會觸發Znode上註冊的對應事件，請求Watch的客戶端會接收到非同步通知。

具體互動過程如下：

1.客戶端呼叫getData方法【getData(nodePath,isWatch)】，watch引數是true。服務端接到請求，返回節點資料，並且在對應的雜湊表裡插入被Watch的Znode路徑，以及Watcher列表。

2.當被Watch的Znode已刪除，服務端會查詢雜湊表，找到該Znode對應的所有Watcher，非同步通知客戶端，並且刪除雜湊表中對應的Key-Value。

zk的應用

講到zk的應用，肯定得想到zk有什麼作用，才能知道它能做什麼？

zk可以用來 協調分散式服務、共享變數、協調鎖資源、提供名稱空間，其實這些作用是依賴zk的資料模型以及ZNode的資料結構，也可以從側面反映出，先有功能需求 才能想出 好的資料模型及資料結構。

好了，我們平常會將zk用來做什麼？

1.分散式鎖

這是雅虎研究員設計Zookeeper的初衷。利用Zookeeper的臨時順序節點，可以輕鬆實現分散式鎖。

2.服務註冊和發現

利用Znode和Watcher，可以實現分散式服務的註冊和發現。最著名的應用就是阿里的分散式RPC框架Dubbo。

3.共享配置和狀態資訊

Redis的分散式解決方案Codis，就利用了Zookeeper來存放資料路由表和codis-proxy 節點的元資訊。同時 codis-config 發起的命令都會通過 ZooKeeper 同步到各個存活的 codis-proxy。

此外，Kafka、HBase、Hadoop，也都依靠Zookeeper同步節點資訊，實現高可用。

4.其實它還可以用來解決分散式Id生成，只不過zk的zNode支援的數量不夠多，因為zk主要使用場景是那種讀多寫少的，

好了，插個小廣告，我自己 基於netty4+twitter-snowFlake 寫了個分散式Id生成之服務：https://github.com/Zeb-D/distributed-id ；關於這開源專案，我後續會單獨寫個系列的部落格。

zk的叢集

叢集單純地防止單個zk掛了，導致所有依賴zk的服務都不可用（或者被影響到），其實zkClient 這會在呼叫方 會快取下來一下zk Server的資料，具體是怎麼個樣子，可能需要單獨研究分析下，博主目前不知道怎麼去分析，希望各位老道們給點建議，謝謝！

ZookeeperService叢集是一主多從結構。

在更新資料時，首先更新到主節點（這裡的節點是指伺服器，不是Znode），再同步到從節點。

在讀取資料時，直接讀取任意從節點。

說到這一主多從叢集方式，大家可能會聯想到Mysql叢集方式，這種叢集方式保證服務高可用，但又是如何保證各個主從節點任意時間的資料一致性呢？

zk的一致性

為了保證主從節點的資料一致性，Zookeeper採用了ZAB協議，這種協議非常類似於一致性演算法Paxos和Raft。

ZAB協議

我們需要首先了解ZAB協議所定義的三種節點狀態：

Looking ：選舉狀態。

Following：Follower節點（從節點）所處的狀態。

Leading：Leader節點（主節點）所處狀態。

我們還需要知道最大ZXID的概念：

最大ZXID也就是節點本地的最新事務編號，包含epoch和計數兩部分。epoch是紀元的意思，相當於Raft演算法選主時候的term。

zk主節點故障恢復

假如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。

自此，故障恢復正式完成。

ZAB寫資料

在上面的zk叢集圖，可用看出zk客戶端是輪詢到某個zk Server的，那這是如何工作及保證資料一致性的，這主要用的了廣播 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和版本號，保證了資料的更新和讀取是有序的。