分佈式協調神器 ZooKeeper 之總體概述

ZooKeeper 最先起源於雅虎研究院的一個研究小組。當時，雅虎內部不少大型系統基本都須要依賴一個相似的系統來進行分佈式協調，可是這些系統每每都存在分佈式單點問題。因此，雅虎的開發人員就試圖開發一個通用的無單點問題的分佈式協調框架，以便讓開發人員將精力集中在處理業務邏輯上。

立項初期，考慮到以前內部不少項目都是使用動物的名字來命名的（例如著名的 Pig 項目)，雅虎的工程師但願給這個項目也取一個動物的名字。當時研究院的首席科學家 RaghuRamakrishnan 開玩笑說：「再這樣下去，咱們這兒就變成動物園了！」是否是頗有趣，順勢你們就表示既然已是動物園了，它就叫動物園管理員吧！各個以動物命名的分佈式組件放在一塊兒，雅虎的整個分佈式系統看上去就像一個大型的動物園了，而 ZooKeeper 正好要用來進行分佈式環境的協調一一因而，ZooKeeper 的名字也就由此誕生了！

ZooKeeper概述

ZooKeeper 是一種用於分佈式應用程序的分佈式開源協調服務。它公開了一組簡單的原語，分佈式應用程序能夠構建這些原語，以實現更高級別的服務，以實現同步，配置維護以及組和命名。它被設計爲易於編程，並使用在熟悉的文件系統目錄樹結構以後設計的數據模型。它在Java中運行，而且具備Java和C的綁定。

衆所周知，協調服務很難作到。他們特別容易出現諸如競爭條件和死鎖等錯誤。ZooKeeper 背後的動機是減輕分佈式應用程序從頭開始實施協調服務的責任。

集羣模型

Leader 服務器是整個 ZooKeeper 集羣工做機制中的核心，其主要工做有如下兩個：

1. 事務請求的惟一調度和處理者，保證集羣事務處理的順序性。

2. 集羣內部各服務器的調度者。

從角色名字上能夠看出，Follewer 服務器是 ZooKeeper 集羣狀態的跟隨者，其主要工做有如下三個：

1. 處理客戶端非事務請求，轉發事務請求給 Leader 服務器。

2. 參與事務請求 Proposal 的投票。

3. 參與 Leader 選舉投票。

Observer 充當了一個觀察者的角色，在工做原理上基本和 Follower 一致，惟一的區別在於，它不參與任何形式的投票。

數據結構

 

樹形結構

首先咱們來看上述數據節點示意圖，從而對 ZooKeeper 上的數據節點有一個大致上的認識，在 ZooKeeper 中，每個節點都被稱爲一個 ZNode，全部 ZNode 按層次化機構進行組織，造成一棵樹。ZNode 節點路徑標識方式和 Unix 文件系統路徑很是類似，都是由一系列使用斜槓（/）進行分割的路徑表示，開發人員能夠向這個節點中寫入數據，也能夠在節點下面建立子節點。

節點操做流程

 

1. 在 Client 向 Follower 發出一個寫請求。

2. Follower 把請求轉發給 Leader。

3. Leader 接收到之後開始發起投票並通知 Follower 進行投票。

4. Follower 把投票結果發送給 Leader。

5. Leader 將結果彙總後，若是須要寫入，則開始寫入，同時把寫入操做通知給 Follower，而後 commit。

6. Follower 把請求結果返回給 Client。

 

設計目標

1. 順序一致性，來自任意特定客戶端的更新都會按其發送順序被提交。也就是說，若是一個客戶端將 Znode z 的值更新爲 a，在以後的操做中，它又將 z 的值更新爲 b，則沒有客戶端可以在看到z的值是b以後再看到值 a（若是沒有其餘對z的更新）。

2. 原子性，每一個更新要麼成功，要麼失敗。這意味着若是一個更新失敗，則不會有客戶端會看到這個更新的結果。

3. 單一系統映像，一個客戶端不管鏈接到哪一臺服務器，它看到的都是一樣的系統視圖。這意味着，若是一個客戶端在同一個會話中鏈接到一臺新的服務器，它所看到的系統狀態不會比 在以前服務器上所看到的更老。當一臺服務器出現故障，致使它的一個客戶端須要嘗試鏈接集合體中其餘的服務器時，全部滯後於故障服務器的服務器都不會接受該 鏈接請求，除非這些服務器遇上故障服務器。

4. 持久性，一個更新一旦成功，其結果就會持久存在而且不會被撤銷。這代表更新不會受到服務器故障的影響。

 

總體架構

 

• ServerCnxnFactory，ZooKeeper服務端網絡鏈接工廠。在早期版本中，ZooKeeper 都是本身實現 NIO 框架，從 3.4.0 版本開始，引入了 Netty。能夠經過 zookeeper.serverCnxnFactory 來指定使用具體的實現。

• SessionTracker，ZooKeeper 服務端會話管理器。建立時，會初始化 expirationInterval、nextExpirationTime、sessionsWithTimeout（用於保存每一個會話的超時時間），同時還會計算出一個初始化的sessionID。

• RequestProcessor，ZooKeeper的請求處理方式是典型的責任鏈模式，在服務端，會有多個請求處理器依次來處理一個客戶的請求。在服務器啓動的時候，會將這些請求處理器串聯起來造成一個請求處理鏈。基本的請求處理鏈以下：

• LearnerCnxAcceptor，Learner服務器（等於 Follower 服務器）鏈接請求接收器。負責 Leader 服務器和 Follower 服務器保持鏈接，以肯定集羣機器存活狀況，並處理鏈接請求。

• LearnerHandler，Leader 接收來自其餘機器的鏈接建立請求後，會建立一個 LearnerHandler 實例。每一個 LearnerHandler 實例都對應了一個 Leader 和 Learner 服務器之間的鏈接，其負責 Leader 和 Learner 服務器之間幾乎全部的消息通訊和數據同步。

• ZKDatabase，ZooKeeper 內存數據庫，負責管理 ZooKeeper 的全部會話記錄以及 DataTree 和事務日誌的存儲。

• FileTxnSnapLog，ZooKeeper 上層服務和底層數據存儲之間的對接層，提供了一系列的操做數據文件的接口，包括事務文件和快照數據文件。ZooKeeper 根據 zoo.cfg 文件中解析出的快照數據目錄 dataDir 和事務日誌目錄 dataLogDir 來建立 FileTxnSnapLog。

• LeaderElection，ZooKeeper 會根據 zoo.cfg 中的配置，建立相應的 Leader 選舉算法實現。在 ZooKeeper 中，默認提供了三種 Leader 選舉算法的實現，分別是 LeaderElection、AuthFastLeaderElection、FastLeaderElection，能夠經過配置文件中 electionAlg 屬性來指定，分別用 0 ~ 3 來表示。從 3.4.0 版本開始，ZooKeeper 廢棄了前兩種算法，只支持 FastLeaderEletion 選舉算法。