Zookeeper作業程序詳解

一、Zookeeper作業機制

分布式和集中式系統相比，有很多優勢，比如更強的計算能力，存盤能力，避免單點故障等問題，但是由于在分布式部署的方式遇到網路故障等問題的時候怎么保證各個節點資料的一致性和可用性是比較關鍵的問題，

那么，對于分布式集群來說，我們需要一個能夠在各個服務和節點之間進行協調和服務的中間人——Zookeeper，

Zookeeper從設計模式角度來理解：是一個基于觀察者模式設計的分布式服務管理框架，負責存盤和管理大家都關心的資料，然后接受觀察者的注冊，一旦這些資料的狀態發生變化，Zookeeper就將負責通知已經在Zookeeper上注冊的那些觀察者做出相應的回應，

二、資料結構

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

三、選舉機制

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）統計投票，每次投票后，服務器都會統計投票資訊，判斷是否已經有過半機器接受到相同的投票資訊，對于Server1、Server2而言，都統計出集群中已經有兩臺機器接受了(2, 0)的投票資訊，此時便認為已經選出了Leader，一旦選出leader，后邊的機器不管myid和ZXID多大，都自動成為leader的小弟

（6）改變服務器狀態，一旦確定了Leader，每個服務器就會更新自己的狀態，如果是Follower，那么就變更為FOLLOWING，如果是Leader，就變更為LEADING

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

與啟動時不同的就是，每個服務器上都有歷史資料，在選舉之前，首先非leader的服務器改變狀態為LOOKING狀態，因為運行期間每個服務器ZXID不同，會和啟動時的選舉一樣進行重新投票選舉，

四、監聽機制

1. 首先要有一個main()執行緒
2. 在main執行緒中創建Zookeeper客戶端，這時就會創建兩個執行緒，一個負責網路連接通信（connet），一個負責監聽（listener）
3. 通過connect執行緒將注冊的監聽事件發送給Zookeeper
4. 在Zookeeper的注冊監聽器串列中將注冊的監聽事件添加到串列中
5. Zookeeper監聽到有資料或路徑變化，就會將這個訊息發送給listener執行緒
6. listener執行緒內部呼叫了process（）方法

五、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

六、應用場景

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

標籤：大數據

上一篇：跪求Crystal Reports 8.0,帶設計器,能編輯8.0版的rpt檔案

下一篇：mysql 5.7 sql_mode修改后無效