Zookeeper工做過程詳解

1、Zookeeper工做機制

分佈式和集中式系統相比，有不少優點，好比更強的計算能力，存儲能力，避免單點故障等問題。可是因爲在分佈式部署的方式遇到網絡故障等問題的時候怎麼保證各個節點數據的一致性和可用性是比較關鍵的問題。

那麼，對於分佈式集羣來講，咱們須要一個可以在各個服務和節點之間進行協調和服務的中間人——Zookeeper。

Zookeeper從設計模式角度來理解：是一個基於觀察者模式設計的分佈式服務管理框架，負責存儲和管理你們都關心的數據，而後接受觀察者的註冊，一旦這些數據的狀態發生變化，Zookeeper就將負責通知已經在Zookeeper上註冊的那些觀察者作出相應的迴應。

2、數據結構

Zookeeper的數據結構和linux的目錄結構相似，也像數據結構中的樹，以下圖：

Zookeeper的數據存儲基於節點，這種節點稱爲Znode。Znode的引用方式是路徑的引用，每一個Znode均可以經過其路徑惟一標識。

其中Znode中包含有：數據，子節點引用，訪問權限等，以下圖：

• data：Znode存儲的數據信息
• ACL：記錄Znode的訪問權限，即哪些人或哪些IP能夠訪問本節點
• child：當前節點的子節點引用，相似於二叉樹的左孩子右孩子
• stat：包含Znode的各類元數據，好比事務ID、版本號、時間戳、大小等等

stat 查看根目錄的詳細信息：

[zk: localhost:2181(CONNECTED) 0] stat /
cZxid = 0x0
ctime = Thu Jan 01 08:00:00 CST 1970
mZxid = 0x0
mtime = Thu Jan 01 08:00:00 CST 1970
pZxid = 0x0
cversion = -1
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 0
numChildren = 1

3、選舉機制

Zookeeper集羣是一主多從的模式，主爲leader，從爲follower，其中leader是經過選舉獲得。

Zookeeper集羣有以下特色：

• Zookeeper：一個領導者（leader），多個跟隨者（follower）組成的集羣
• Leader負責進行投票的發起和決議，更新系統狀態
• Follower用於接收客戶請求並向客戶端返回結果，在選舉Leader過程當中參與投票
• 集羣中只要有半數以上節點存活，Zookeeper集羣就能正常服務，因此Zookeeper適合安裝奇數臺服務器
• 全局數據一致：每一個server保存一份相同的數據副本，client不管鏈接到哪一個server，數據都是一致的
• 更新請求順序進行，來自同一個client的更新請求按其發送順序依次執行
• 數據更新原子性，一次數據更新要麼成功，要麼失敗
• 實時性，在必定時間範圍內，client能讀到最新數據

Leader選舉是保證分佈式數據一致性的關鍵所在，當Zookeeper進入如下兩種狀態時，須要進入leader選舉：

1. 服務器初始化啓動
2. leader宕機掛掉

1. 服務器初始化啓動時的選舉

（1）以三臺服務器組成的集羣爲例，在集羣的初始化階段，當server1啓動時，其單獨沒法完成選舉；當server2啓動時，此時兩臺機器能夠互相通訊，每臺機器都試圖找到leader，因而進入選舉狀態

（2）每一個server首先給本身投票：初始階段，每一個服務器都將本身做爲leader來投票，每次投票包含的信息有（myid，ZXID，epoch），此時Server1的投票爲(1, 0)，Server2的投票爲(2, 0)，而後各自將這個投票發給集羣中其餘機器

其中epoch用來判斷多個投票是否在同一輪選舉週期中，該值在服務端是一個自增序列，每次進入新一輪的投票後，都會對該值進行加1操做

（3）每一個server接受來自各個服務器的投票：集羣的每一個服務器收到投票後，首先判斷該投票的有效性，如檢查是不是本輪投票、是否來自LOOKING狀態的服務器

（4）處理投票。針對每個投票，服務器都須要將別人的投票和本身的投票進行PK，PK規則以下：

• 優先檢查ZXID。ZXID比較大的服務器優先做爲Leader
• 若是ZXID相同，那麼就比較myid。myid較大的服務器做爲Leader服務器

對於Server1而言，它的投票是(1, 0)，接收Server2的投票爲(2, 0)，首先會比較二者的ZXID，均爲0，再比較myid，此時Server2的myid最大，因而更新本身的投票爲(2, 0)，而後從新投票，對於Server2而言，其無須更新本身的投票，只是再次向集羣中全部機器發出上一次投票信息便可

（5）統計投票。每次投票後，服務器都會統計投票信息，判斷是否已經有過半機器接受到相同的投票信息，對於Server一、Server2而言，都統計出集羣中已經有兩臺機器接受了(2, 0)的投票信息，此時便認爲已經選出了Leader，一旦選出leader，後邊的機器無論myid和ZXID多大，都自動成爲leader的小弟

（6）改變服務器狀態。一旦肯定了Leader，每一個服務器就會更新本身的狀態，若是是Follower，那麼就變動爲FOLLOWING，若是是Leader，就變動爲LEADING

1. leader服務器掛掉的投票機制

與啓動時不一樣的就是，每一個服務器上都有歷史數據，在選舉以前，首先非leader的服務器改變狀態爲LOOKING狀態，由於運行期間每一個服務器ZXID不一樣，會和啓動時的選舉同樣進行從新投票選舉。

4、監聽機制

1. 首先要有一個main()線程
2. 在main線程中建立Zookeeper客戶端，這時就會建立兩個線程，一個負責網絡鏈接通訊（connet），一個負責監聽（listener）
3. 經過connect線程將註冊的監聽事件發送給Zookeeper
4. 在Zookeeper的註冊監聽器列表中將註冊的監聽事件添加到列表中
5. Zookeeper監聽到有數據或路徑變化，就會將這個消息發送給listener線程
6. listener線程內部調用了process（）方法

5、API應用

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

6、應用場景

Zookeeper提供的服務包括：統一命名服務、統一配置管理、統一集羣管理、服務器節點動態上下線、軟負載均衡等。