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有效解決了Zookeeper集羣崩潰恢復,以及主從同步數據的問題

在學習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。

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

ZAB是怎麼寫入數據的呢?

Broadcast

什麼是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同步節點信息，實現高可用。