ZooKeeper最全詳解(萬字圖文總結)

來源：mikechen的網際網路架構

ZooKeeper是一個分散式協調服務，是分散式系統的核心元件，下面我全面詳解ZooKeeper

Zookeeper

Zookeeper 是一個開源的分散式  協調服務框架，它是一個為分散式應用提供一致性服務的軟體。

Zookeeper 致力於提供一個高效能、高可用，且具備嚴格的順序訪問控制能力的分 布式協調服務，是雅虎公司建立，是 Google 的 Chubby 一個開源的實現。

Zookeeper核心功能

主要提供了三個核心功能：

1.檔案系統

zk的儲存的資料的結構，類似於一個檔案系統。

每個節點稱為znode，每個znode都是一個類似於KV的結構，每個節點名稱相當於key，每個節點中都儲存了對應的資料，類似於Key對應的value。每個znode下面都可以有多個子節點，就這樣一直延續下去，構成了類似於Linux檔案系統的架構。

2.通知機制

當某個client監聽某個節點時，當該節點發生變化時（有可能是增加子節點，或者節點值變了等），zk就會通知監聽該節點的客戶端來處理。

3.叢集管理機制

zk本身是一個叢集結構，有一個leader節點，負責寫請求，多個follower負責響應讀請求。並且在leader節點故障時，會自動根據選舉機制從剩下的follower中選出新的leader。

 Zookeeper的應用場景

1.命名服務Name Service

依賴Zookeeper可以生成全域性唯一的節點ID，來對分散式系統中的資源進行管理。

2.分散式協調

這是Zookeeper的核心使用了，利用Watch的監聽機制，一個系統的某個節點狀態發生改變，另外系統可以得到通知。

3.叢集管理

分散式叢集中狀態的監控和管理，使用Zookeeper來儲存。

4.分散式鎖

利用Zookeeper建立臨時順序節點的特性。

Zookeeper協議

使用ZAB協議，全稱 Zookeeper Atomic Broadcast，從名字可以看出，Zab 協議是一種原子性的訊息廣播協議。

Zab 協議借鑑了 Paxos 演算法，具有一些相似之處，從設計上看，ZAB協議和 Raft 很類似，是一種通用的分散式一致性演算法，它是特別為 Zookeeper 設計的支援崩潰恢復的原子廣播協議。

如果覺得對Paxos 協議難以理解，建議學習Raft協議，ZAB本質與Raft是類似的。

Zookeeper的工作模式

1.Zookeeper從設計模式的角度理解，是一個基於觀察者模式設計的分散式服務管理框架。

2.基於事件監聽通知，監聽註冊到上面的節點的動向（修改、新增、刪除），會實時的通知訪問客戶端。

3.選舉機制，中心化思想，分為主從操作，進行分散式控制所有slave之間的同步決策。

Zookeeper的角色？

1.leader角色

處理所有的事務請求（寫請求），可以處理讀請求，叢集中只能有一個Leader

2. Follower角色

只能處理讀請求，同時作為 Leader的候選節點，即如果Leader當機，Follower節點要參與到新的Leader選舉中，有可能成為新的Leader節點。

3. Observer角色

Observer：只能處理讀請求,不能參與選舉。

Zookeeper節點型別

提供了四種型別的資料節點 Znode：

1.持久節點

除非手動刪除，否則節點一直存在於Zookeeper上

2.持久順序節點

基本特性同持久節點，只是增加了順序屬性，節點名後邊會追加一個由父節點維護的自增整型數字

3.臨時節點

客戶端與Zookeeper斷開連線後，該節點被刪除

4.臨時順序節點

基本特性同臨時節點，增加了順序屬性，節點名後邊會追加一個由父節點維護的自增整型數字

Zookeeper架構與叢集

叢集為2N+1臺，N>0，比如N為1的情況就是3臺。

為什麼是3臺而不是2臺呢？因為叢集需要一半以上的機器可用，所以，3臺掛掉1臺還能工作，2臺不能。

ZAB協議核心階段

Zab 協議的原理可細分為四個階段：選舉（Leader Election）、發現（Discovery）、同步（Synchronization）和廣播（Broadcast）。

1.Leader election(選舉階段)

節點在一開始都處於選舉階段，只要有一個節點得到超過半數節點的票數，它就可以當選準 Leader。

2.Discovery(發現階段)

在這個階段，Followers跟準Leader進行通訊，同步Followers最近接收的事務提議。

3.Synchronization(同步階段)

同步階段主要是利用Leader前一階段獲得的最新提議歷史，同步叢集中所有的副本。同步完成之後準Leader才會成為真正的Leader。

4.Broadcast(廣播階段)

到了這個階段，Zookeeper叢集才能正式對外提供事務服務，並且Leader 可以進行訊息廣播。同時如果有新的節點加入，還需要對新節點進行同步。

Zookeeper 的資料模型

在 Zookeeper 中，可以說 Zookeeper 中的所有儲存的資料是由 znode 組成的，節點也稱為 znode，並以 key/value 形式儲存資料。

整體結構類似於 linux 檔案系統的模式以樹形結構儲存。其中根路徑以 / 開頭。

Zookeeper如何選舉新的leader

當Zookeeper叢集在啟動時，或者當leader節點出現網路中斷、崩潰等情況時，Zookeeper就會進入恢復模式並選舉產生新的 Leader。

第一步:每個Server發出一個投票

第二步:接收來自各個伺服器的投票

第三步:PK選票並更新選票

第四步:統計所有投票，判斷是否有過半機器接收到相同的投票資訊

第五步:改變伺服器狀態

一旦確定Leader，每個伺服器更新自己的狀態

Zookeeper實現分散式鎖

常見的分散式鎖實現方案裡面，除了使用redis來實現之外，使用Zookeeper也可以實現分散式鎖。

Zookeeper 分散式鎖是基於 臨時順序節點 來實現的，鎖可理解為 Zookeeper 上的一個節點，當需要獲取鎖時，就在這個鎖節點下建立一個臨時順序節點。

當存在多個客戶端同時來獲取鎖，就按順序依次建立多個臨時順序節點，但只有排列序號是第一的那個節點能獲取鎖成功，其他節點則按順序分別監聽前一個節點的變化，當被監聽者釋放鎖時，監聽者就可以馬上獲得鎖。

如上圖：ClientA 和 ClientB 同時想獲取鎖，所以都在 locks 節點下建立了一個臨時節點 1 和 2，而 1 是當前 locks 節點下排列序號第一的節點，所以 ClientA 獲取鎖成功，而 ClientB 處於等待狀態，這時 Zookeeper 中的 2 節點會監聽 1 節點，當 1節點鎖釋放（節點被刪除）時，2 就變成了 locks 節點下排列序號第一的節點，這樣 ClientB 就獲取鎖成功了。

Zookeeper通知機制

客戶端註冊監聽他關心的目錄節點，當目錄節點發生變化（資料改變、被刪除、子目錄節點增加刪除）時，Zookeeper會通知客戶端。

client端會對某個znode建立一個watcher事件，當該znode發生變化時，zk會主動通知watch這個znode的client，然後client根據znode的變化來做出業務上的改變等。

watch的整體流程如下圖所示：

主要流程如下：

1.客戶端先向Zookeeper服務端成功註冊想要監聽的節點狀態。

2.同時客戶端本地會儲存該監聽器相關的資訊在WatchManager中。

3.當Zookeeper服務端監聽的資料狀態發生變化時，Zookeeper就會主動通知傳送相應事件資訊給相關會話客戶端，從WatherManager中取出對應Wather物件執行回撥邏輯。