ZooKeeper 典型的應用場景

Zookeeper 從設計模式角度來看，是一個基於觀察者模式設計的分佈式服務管理框架，它負責存儲和管理你們都關心的數據，而後接受觀察者的註冊，一旦這些數據的狀態發生變化，Zookeeper 就將負責通知已經在 Zookeeper 上註冊的那些觀察者作出相應的反應，從而實現集羣中相似 Master/Slave 管理模式，關於 Zookeeper 的詳細架構等內部細節能夠閱讀 Zookeeper 的源碼node

下面詳細介紹這些典型的應用場景，也就是 Zookeeper 到底能幫咱們解決哪些問題？下面將給出答案。數據庫

統一命名服務（Name Service）

分佈式應用中，一般須要有一套完整的命名規則，既可以產生惟一的名稱又便於人識別和記住，一般狀況下用樹形的名稱結構是一個理想的選擇，樹形的名稱結構是一個有層次的目錄結構，既對人友好又不會重複。說到這裏你可能想到了 JNDI，沒錯 Zookeeper 的 Name Service 與 JNDI 可以完成的功能是差很少的，它們都是將有層次的目錄結構關聯到必定資源上，可是 Zookeeper 的 Name Service 更加是普遍意義上的關聯，也許你並不須要將名稱關聯到特定資源上，你可能只須要一個不會重複名稱，就像數據庫中產生一個惟一的數字主鍵同樣。設計模式

Name Service 已是 Zookeeper 內置的功能，你只要調用 Zookeeper 的 API 就能實現。如調用 create 接口就能夠很容易建立一個目錄節點。bash

配置管理（Configuration Management）

配置的管理在分佈式應用環境中很常見，例如同一個應用系統須要多臺 PC Server 運行，可是它們運行的應用系統的某些配置項是相同的，若是要修改這些相同的配置項，那麼就必須同時修改每臺運行這個應用系統的 PC Server，這樣很是麻煩並且容易出錯。markdown

像這樣的配置信息徹底能夠交給 Zookeeper 來管理，將配置信息保存在 Zookeeper 的某個目錄節點中，而後將全部須要修改的應用機器監控配置信息的狀態，一旦配置信息發生變化，每臺應用機器就會收到 Zookeeper 的通知，而後從 Zookeeper 獲取新的配置信息應用到系統中。數據結構

圖 2. 配置管理結構圖

集羣管理（Group Membership）

Zookeeper 可以很容易的實現集羣管理的功能，若有多臺 Server 組成一個服務集羣，那麼必需要一個「總管」知道當前集羣中每臺機器的服務狀態，一旦有機器不能提供服務，集羣中其它集羣必須知道，從而作出調整從新分配服務策略。一樣當增長集羣的服務能力時，就會增長一臺或多臺 Server，一樣也必須讓「總管」知道。架構

Zookeeper 不只可以幫你維護當前的集羣中機器的服務狀態，並且可以幫你選出一個「總管」，讓這個總管來管理集羣，這就是 Zookeeper 的另外一個功能 Leader Election。框架

它們的實現方式都是在 Zookeeper 上建立一個 EPHEMERAL 類型的目錄節點，而後每一個 Server 在它們建立目錄節點的父目錄節點上調用 getChildren(String path, boolean watch) 方法並設置 watch 爲 true，因爲是 EPHEMERAL 目錄節點，當建立它的 Server 死去，這個目錄節點也隨之被刪除，因此 Children 將會變化，這時 getChildren上的 Watch 將會被調用，因此其它 Server 就知道已經有某臺 Server 死去了。新增 Server 也是一樣的原理。分佈式

Zookeeper 如何實現 Leader Election，也就是選出一個 Master Server。和前面的同樣每臺 Server 建立一個 EPHEMERAL 目錄節點，不一樣的是它仍是一個 SEQUENTIAL 目錄節點，因此它是個 EPHEMERAL_SEQUENTIAL 目錄節點。之因此它是 EPHEMERAL_SEQUENTIAL 目錄節點，是由於咱們能夠給每臺 Server 編號，咱們能夠選擇當前是最小編號的 Server 爲 Master，假如這個最小編號的 Server 死去，因爲是 EPHEMERAL 節點，死去的 Server 對應的節點也被刪除，因此當前的節點列表中又出現一個最小編號的節點，咱們就選擇這個節點爲當前 Master。這樣就實現了動態選擇 Master，避免了傳統意義上單 Master 容易出現單點故障的問題。oop

圖 3. 集羣管理結構圖

這部分的示例代碼以下，完整的代碼請看附件：

清單 3. Leader Election 關鍵代碼

void findLeader() throws InterruptedException {

byte[] leader = null;

try {

leader = zk.getData(root + "/leader", true, null);

} catch (Exception e) {

logger.error(e);

}

if (leader != null) {

following();

} else {

String newLeader = null;

try {

byte[] localhost = InetAddress.getLocalHost().getAddress();

newLeader = zk.create(root + "/leader", localhost,

ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL);

} catch (Exception e) {

logger.error(e);

}

if (newLeader != null) {

leading();

} else {

mutex.wait();

}

}

}
複製代碼

共享鎖（Locks）

共享鎖在同一個進程中很容易實現，可是在跨進程或者在不一樣 Server 之間就很差實現了。Zookeeper 卻很容易實現這個功能，實現方式也是須要得到鎖的 Server 建立一個 EPHEMERAL_SEQUENTIAL 目錄節點，而後調用 getChildren方法獲取當前的目錄節點列表中最小的目錄節點是否是就是本身建立的目錄節點，若是正是本身建立的，那麼它就得到了這個鎖，若是不是那麼它就調用 exists(String path, boolean watch) 方法並監控 Zookeeper 上目錄節點列表的變化，一直到本身建立的節點是列表中最小編號的目錄節點，從而得到鎖，釋放鎖很簡單，只要刪除前面它本身所建立的目錄節點就好了。

圖 4. Zookeeper 實現 Locks 的流程圖

同步鎖的實現代碼以下，完整的代碼請看附件：

清單 4. 同步鎖的關鍵代碼

void getLock() throws KeeperException, InterruptedException{

List<``String``> list = zk.getChildren(root, false);

String[] nodes = list.toArray(new String[list.size()]);

Arrays.sort(nodes);

if(myZnode.equals(root+"/"+nodes[0])){

doAction();

}

else{

waitForLock(nodes[0]);

}

}

void waitForLock(String lower) throws InterruptedException, KeeperException {

Stat stat = zk.exists(root + "/" + lower,true);

if(stat != null){

mutex.wait();

}

else{

getLock();

}

}
複製代碼

隊列管理

Zookeeper 能夠處理兩種類型的隊列：

1. 當一個隊列的成員都聚齊時，這個隊列纔可用，不然一直等待全部成員到達，這種是同步隊列。 2. 隊列按照 FIFO 方式進行入隊和出隊操做，例如實現生產者和消費者模型。

同步隊列用 Zookeeper 實現的實現思路以下：

建立一個父目錄 /synchronizing，每一個成員都監控標誌（Set Watch）位目錄 /synchronizing/start 是否存在，而後每一個成員都加入這個隊列，加入隊列的方式就是建立 /synchronizing/member_i 的臨時目錄節點，而後每一個成員獲取 / synchronizing 目錄的全部目錄節點，也就是 member_i。判斷 i 的值是否已是成員的個數，若是小於成員個數等待 /synchronizing/start 的出現，若是已經相等就建立 /synchronizing/start。

用下面的流程圖更容易理解：

圖 5. 同步隊列流程圖

同步隊列的關鍵代碼以下，完整的代碼請看附件：

清單 5. 同步隊列

void addQueue() throws KeeperException, InterruptedException{

zk.exists(root + "/start",true);

zk.create(root + "/" + name, new byte[0], Ids.OPEN_ACL_UNSAFE,

CreateMode.EPHEMERAL_SEQUENTIAL);

synchronized (mutex) {

List<``String``> list = zk.getChildren(root, false);

if (list.size() < size) {

mutex.wait();

} else {

zk.create(root + "/start", new byte[0], Ids.OPEN_ACL_UNSAFE,

CreateMode.PERSISTENT);

}

}

}
複製代碼

當隊列沒盡是進入 wait()，而後會一直等待 Watch 的通知，Watch 的代碼以下：

public void process(WatchedEvent event) {

if(event.getPath().equals(root + "/start") &&

event.getType() == Event.EventType.NodeCreated){

System.out.println("獲得通知");

super.process(event);

doAction();

}

}
複製代碼

FIFO 隊列用 Zookeeper 實現思路以下：

實現的思路也很是簡單，就是在特定的目錄下建立 SEQUENTIAL 類型的子目錄 /queue_i，這樣就能保證全部成員加入隊列時都是有編號的，出隊列時經過 getChildren( ) 方法能夠返回當前全部的隊列中的元素，而後消費其中最小的一個，這樣就能保證 FIFO。

下面是生產者和消費者這種隊列形式的示例代碼，完整的代碼請看附件：

清單 6. 生產者代碼

boolean produce(int i) throws KeeperException, InterruptedException{

ByteBuffer b = ByteBuffer.allocate(4);

byte[] value;

b.putInt(i);

value = b.array();

zk.create(root + "/element", value, ZooDefs.Ids.OPEN_ACL_UNSAFE,

CreateMode.PERSISTENT_SEQUENTIAL);

return true;

}
複製代碼

清單 7. 消費者代碼

int consume() throws KeeperException, InterruptedException{

int retvalue = -1;

Stat stat = null;

while (true) {

synchronized (mutex) {

List<``String``> list = zk.getChildren(root, true);

if (list.size() == 0) {

mutex.wait();

} else {

Integer min = new Integer(list.get(0).substring(7));

for(String s : list){

Integer tempValue = new Integer(s.substring(7));

if(tempValue < min) min = tempValue;

}

byte[] b = zk.getData(root + "/element" + min,false, stat);

zk.delete(root + "/element" + min, 0);

ByteBuffer buffer = ByteBuffer.wrap(b);

retvalue = buffer.getInt();

return retvalue;

}

}

}

}
複製代碼

總結

Zookeeper 做爲 Hadoop 項目中的一個子項目，是 Hadoop 集羣管理的一個必不可少的模塊，它主要用來控制集羣中的數據，如它管理 Hadoop 集羣中的 NameNode，還有 Hbase 中 Master Election、Server 之間狀態同步等。

本文介紹的 Zookeeper 的基本知識，以及介紹了幾個典型的應用場景。這些都是 Zookeeper 的基本功能，最重要的是 Zoopkeeper 提供了一套很好的分佈式集羣管理的機制，就是它這種基於層次型的目錄樹的數據結構，並對樹中的節點進行有效管理，從而能夠設計出多種多樣的分佈式的數據管理模型，而不只僅侷限於上面提到的幾個經常使用應用場景。