分布式服務框架 Zookeeper

Zookeeper名字的由來是比較有趣的，下面的片段摘抄自《從PAXOS到ZOOKEEPER分布式一致性原理與實踐》一書：

Zookeeper最早起源于雅虎的研究院的一個研究小組。在當時，研究人員發(fā)現，在雅虎內部很多大型的系統需要依賴一個類似的系統進行分布式協調，但是這些系統往往存在分布式單點問題。所以雅虎的開發(fā)人員就試圖開發(fā)一個通用的無單點問題的分布式協調框架。在立項初期，考慮到很多項目都是用動物的名字來命名的(例如著名的Pig項目)，雅虎的工程師希望給這個項目也取一個動物的名字。時任研究院的首席科學家Raghu Ramakrishnan開玩笑說：再這樣下去，我們這兒就變成動物園了。此話一出，大家紛紛表示就叫動物園管理員吧——因為各個以動物命名的分布式組件放在一起，雅虎的整個分布式系統看上去就像一個大型的動物園了，而Zookeeper正好用來進行分布式環(huán)境的協調——于是，Zookeeper的名字由此誕生了。

Zookeeper 分布式服務框架是 Apache Hadoop 的一個子項目，它主要是用來解決分布式應用中經常遇到的一些數據管理問題，如：統一命名服務、狀態(tài)同步服務、集群管理、分布式應用配置項的管理等。本文將 從使用者角度詳細介紹 Zookeeper 的安裝和配置文件中各個配置項的意義，以及分析 Zookeeper 的典型的應用場景（配置文件的管理、集群管理、同步鎖、Leader 選舉、隊列管理等），用 Java 實現它們并給出示例代碼。

安裝和配置詳解

本文介紹的 Zookeeper 是以 3.4.5 這個穩(wěn)定版本為基礎，最新的版本可以通過官網 http://hadoop.apache.org/zookeeper/來獲取，Zookeeper 的安裝非常簡單，下面將從單機模式和集群模式兩個方面介紹 Zookeeper 的安裝和配置。

單機模式

單機安裝非常簡單，只要獲取到 Zookeeper 的壓縮包并解壓到某個目錄如：/home/zookeeper-3.4.5 下，Zookeeper 的啟動腳本在 bin 目錄下，Linux 下的啟動腳本是 zkServer.sh。

在你執(zhí)行啟動腳本之前，還有幾個基本的配置項需要配置一下，Zookeeper 的配置文件在 conf 目錄下，這個目錄下有 zoo_sample.cfg 和 log4j.properties，你需要做的就是將 zoo_sample.cfg 改名為 zoo.cfg，因為 Zookeeper 在啟動時會找這個文件作為默認配置文件。下面詳細介紹一下，這個配置文件中各個配置項的意義。

• tickTime=2000

tickTime：這個時間是作為 Zookeeper 服務器之間或客戶端與服務器之間維持心跳的時間間隔，也就是每個 tickTime 時間就會發(fā)送一個心跳。

• dataDir=D:/software/zookeeper-3.4.5/data

dataDir：顧名思義就是 Zookeeper 保存數據的目錄，默認情況下，Zookeeper 將寫數據的日志文件也保存在這個目錄里。

• clientPort=2181

clientPort：這個端口就是客戶端連接 Zookeeper 服務器的端口，Zookeeper 會監(jiān)聽這個端口，接受客戶端的訪問請求。

當這些配置項配置好后，你現在就可以啟動 Zookeeper 了，啟動后要檢查 Zookeeper 是否已經在服務，可以通過 lsof -i:2181 命令查看是否有你配置的 clientPort 端口號在監(jiān)聽服務。

集群模式

Zookeeper 不僅可以單機提供服務，同時也支持多機組成集群來提供服務。實際上 Zookeeper 還支持另外一種偽集群的方式，也就是可以在一臺物理機上運行多個 Zookeeper 實例，下面將介紹集群模式的安裝和配置。

Zookeeper 的集群模式的安裝和配置也不是很復雜，所要做的就是增加幾個配置項。集群模式除了上面的三個配置項還要增加下面幾個配置項：

• initLimit=5

initLimit：這個配置項是用來配置 Zookeeper 接受客戶端（這里所說的客戶端不是用戶連接 Zookeeper 服務器的客戶端，而是 Zookeeper 服務器集群中連接到 Leader 的 Follower 服務器）初始化連接時最長能忍受多少個心跳時間間隔數。當已經超過 5 個心跳的時間（也就是 tickTime）長度后 Zookeeper 服務器還沒有收到客戶端的返回信息，那么表明這個客戶端連接失敗。總的時間長度就是 5*2000=10 秒。

• syncLimit=2

syncLimit：這個配置項標識 Leader 與 Follower 之間發(fā)送消息，請求和應答時間長度，最長不能超過多少個 tickTime 的時間長度，總的時間長度就是 2*2000=4 秒。

• server.1=192.168.211.1:2888:3888
  
  server.2=192.168.211.2:2888:3888
  
  server.3=192.168.211.3:2888:3888

server.A=B：C：D，其中 A 是一個數字，表示這個是第幾號服務器；B 是這個服務器的 ip 地址；C 表示的是這個服務器與集群中的 Leader 服務器交換信息的端口；D 表示的是萬一集群中的 Leader 服務器掛了，需要一個端口來重新進行選舉，選出一個新的 Leader，而這個端口就是用來執(zhí)行選舉時服務器相互通信的端口。如果是偽集群的配置方式，由于 B 都是一樣，所以不同的 Zookeeper 實例通信端口號不能一樣，所以要給它們分配不同的端口號。

除了修改 zoo.cfg 配置文件，集群模式下還要配置一個文件 myid，這個文件在 dataDir 目錄下，這個文件里面只有一個數據就是 A 的值，Zookeeper 啟動時會讀取這個文件，拿到里面的數據與 zoo.cfg 里面的配置信息比較從而判斷到底是哪個 server。

數據模型

Zookeeper 會維護一個具有層次關系的數據結構，它非常類似于一個標準的文件系統，如圖 1 所示：

圖 1 Zookeeper 數據結構

image.png

Zookeeper 這種數據結構有如下這些特點：

1. 每個子目錄項如 NameService 都被稱作為 znode，這個 znode 是被它所在的路徑唯一標識，如 Server1 這個 znode 的標識為 /NameService/Server1
2. znode 可以有子節(jié)點目錄，并且每個 znode 可以存儲數據，注意 EPHEMERAL 類型的目錄節(jié)點不能有子節(jié)點目錄
3. znode 是有版本的，每個 znode 中存儲的數據可以有多個版本，也就是一個訪問路徑中可以存儲多份數據
4. znode 可以是臨時節(jié)點，一旦創(chuàng)建這個 znode 的客戶端與服務器失去聯系，這個 znode 也將自動刪除，Zookeeper 的客戶端和服務器通信采用長連接方式，每個客戶端和服務器通過心跳來保持連接，這個連接狀態(tài)稱為 session，如果 znode 是臨時節(jié)點，這個 session 失效，znode 也就刪除了
5. znode 的目錄名可以自動編號，如 App1 已經存在，再創(chuàng)建的話，將會自動命名為 App2
6. znode 可以被監(jiān)控，包括這個目錄節(jié)點中存儲的數據的修改，子節(jié)點目錄的變化等，一旦變化可以通知設置監(jiān)控的客戶端，這個是 Zookeeper 的核心特性，Zookeeper 的很多功能都是基于這個特性實現的，后面在典型的應用場景中會有實例介紹

原生API

Zookeeper 作為一個分布式的服務框架，主要用來解決分布式集群中應用系統的一致性問題，它能提供基于類似于文件系統的目錄節(jié)點樹方式的數據存儲，但是 Zookeeper 并不是用來專門存儲數據的，它的作用主要是用來維護和監(jiān)控你存儲的數據的狀態(tài)變化。通過監(jiān)控這些數據狀態(tài)的變化，從而可以達到基于數據的集群管理，后面將會詳細介紹 Zookeeper 能夠解決的一些典型問題，這里先介紹一下，Zookeeper 的操作接口和簡單使用示例。

常用接口列表

客戶端要連接 Zookeeper 服務器可以通過創(chuàng)建 org.apache.zookeeper. ZooKeeper 的一個實例對象，然后調用這個類提供的接口來和服務器交互。

前面說了 ZooKeeper 主要是用來維護和監(jiān)控一個目錄節(jié)點樹中存儲的數據的狀態(tài)，所有我們能夠操作 ZooKeeper 的也和操作目錄節(jié)點樹大體一樣，如創(chuàng)建一個目錄節(jié)點，給某個目錄節(jié)點設置數據，獲取某個目錄節(jié)點的所有子目錄節(jié)點，給某個目錄節(jié)點設置權限和監(jiān)控這個目錄節(jié)點的狀態(tài)變化。

這些接口如下表所示：

除了以上這些列出的方法之外還有一些重載方法，如都提供了一個回調類的重載方法以及可以設置特定 Watcher 的重載方法，具體的方法可以參考 org.apache.zookeeper.ZooKeeper 類的 API 說明。

基本操作

下面給出操作 ZooKeeper 的示例代碼，這樣你就能對 ZooKeeper 有直觀的認識了。下面的清單包括了創(chuàng)建與 ZooKeeper 服務器的連接以及最基本的數據操作：

public class ZookeeperWatcher implements Watcher {
    private ZooKeeper zk;
    private CountDownLatch latch = new CountDownLatch(1);
    private static final String CONNECTION_STR = "127.0.0.1:2181";
    // 會話超時時間，參見下文對會話超時的描述
    private static final int SESSION_TIMEOUT = 10000;
    
    public ZookeeperWatcher() {
        try {
            zk = new ZooKeeper(CONNECTION_STR, SESSION_TIMEOUT, this);
            System.out.println("開始建立zk連接...");
            // 阻塞直到連接建立完畢
            latch.await();
        } catch (Exception e) {
            if (zk != null) {
                try {
                    zk.close();
                    zk = null;
                } catch (InterruptedException e1) {
                    e1.printStackTrace();
                }
            }
            e.printStackTrace();
        }
    }
    
    @Override
    public void process(WatchedEvent event) {
        String path = event.getPath();
        System.out.println("受影響路徑：" + path);
        
        KeeperState keeperState = event.getState();
        EventType eventType = event.getType();
        
        if (KeeperState.SyncConnected == keeperState) {
            if (EventType.None == eventType) {
                // 成功建立連接
                System.out.println("event:成功建立與zk服務器的連接");
                // 連接建立完成，通知程序往下執(zhí)行
                latch.countDown();
            }
            
            if (EventType.NodeChildrenChanged == eventType) {
                // 子節(jié)點發(fā)生變化
                System.out.println("event:子節(jié)點發(fā)生變化");
            }
            
            if (EventType.NodeCreated == eventType) {
                // 節(jié)點被創(chuàng)建
                System.out.println("event:節(jié)點被創(chuàng)建");
            }
            
            if (EventType.NodeDataChanged == eventType) {
                // 節(jié)點數據發(fā)生變化
                System.out.println("event:節(jié)點數據發(fā)生變化");
            }
            
            if (EventType.NodeDeleted == eventType) {
                // 節(jié)點被刪除
                System.out.println("event:節(jié)點被刪除");
            }
        }
        
        if (KeeperState.Disconnected == keeperState) {
            System.out.println("斷開與zk的連接");
        }
        
        if (KeeperState.AuthFailed == keeperState) {
            System.out.println("認證失敗");
        }
        
        if (KeeperState.Expired == keeperState) {
            System.out.println("會話超時");
        }
    }
    
    /**
     * 創(chuàng)建節(jié)點
     * @param path
     * @param data
     * @param needWatch
     */
    public void createNode(String path, String data, boolean needWatch) {
        try {
            Stat stat = this.zk.exists(path, needWatch);
            if (stat == null) {
                String res = this.zk.create(path, data.getBytes(), Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);
                System.out.println("節(jié)點創(chuàng)建完成" + res);
            } else {
                System.out.println(path + " already exists..[" + stat + "]");
            }
        } catch (KeeperException e) {
            e.printStackTrace();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
    
    /**
     * 創(chuàng)建臨時節(jié)點，會話結束后自動刪除
     * @param path
     * @param data
     */
    public void createTempNode(String path, String data, boolean needWatch) {
        try {
            this.zk.exists(path, needWatch);
            this.zk.create(path, data.getBytes(), Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL);
        } catch (KeeperException e) {
            e.printStackTrace();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
    
    /**
     * 刪除指定節(jié)點
     * @param path
     */
    public void deleteNode(String path) {
        try {
            this.zk.delete(path, -1);
        } catch (InterruptedException e) {
            e.printStackTrace();
        } catch (KeeperException e) {
            e.printStackTrace();
        }
    }
    
    /**
     * 讀取指定節(jié)點的數據
     * @param path
     * @param needWatch
     * @return
     */
    public String getData(String path, boolean needWatch) {
         try {
            String data = new String(this.zk.getData(path, needWatch, null));
            return data;
        } catch (KeeperException e) {
            e.printStackTrace();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return null;
    }
    
    /**
     * 更新指定節(jié)點的數據
     * @param path
     * @param data
     */
    public void writeData(String path, String data) {
        try {
            this.zk.setData(path, data.getBytes(), -1);
        } catch (KeeperException e) {
            e.printStackTrace();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

    /**
     * 判斷指定節(jié)點是否存在
     * @param path 節(jié)點路徑
     */
    public Stat exists(String path, boolean needWatch) {
        try {
            return this.zk.exists(path, needWatch);
        } catch (Exception e) {
            e.printStackTrace();
            return null;
        }
    }

    /**
     * 獲取子節(jié)點
     * @param path 節(jié)點路徑
     */
    public List<String> getChildren(String path, boolean needWatch) {
        try {
            return this.zk.getChildren(path, needWatch);
        } catch (Exception e) {
            e.printStackTrace();
            return null;
        }
    }
    
    /**
     * 關閉連接
     */
    public void closeConnection() {
        if (zk != null) {
            try {
                zk.close();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
    
    public static void main(String[] args) throws Exception {
        ZookeeperWatcher zw = new ZookeeperWatcher();
        
        // 觸發(fā)NodeCreated事件
        zw.createNode("/super", "super", true);
        
        // 觸發(fā)NodeChildrenChanged事件
        List<String> childList = zw.getChildren("/super", true);
        System.out.println(childList);
        zw.createNode("/super/sub", "sub", true);
        
        // 因為watch事件是一次性的，所以需要再次注冊
        zw.getData("/super", true);
        // 觸發(fā)NodeDataChanged事件
        zw.writeData("/super", "newsuper");
        
        // 再次注冊wacth事件
        zw.getData("/super/sub", true);
        // 觸發(fā)NodeDeleted事件
        zw.deleteNode("/super/sub");
        
        Thread.sleep(10000);
        
        
        
        /*
        // 關閉連接，臨時節(jié)點自動被刪除
        ZookeeperWatcher zw = new ZookeeperWatcher();
        zw.createTempNode("/temp", "temp", true);
        zw.exists("/temp", true);
        zw.closeConnection();
        */
        
    }
}

當對目錄節(jié)點監(jiān)控狀態(tài)打開時，一旦目錄節(jié)點的狀態(tài)發(fā)生變化，Watcher 對象的 process 方法就會被調用。

Watch觸發(fā)器

watch概述

ZooKeeper可以為所有的讀操作設置watch，這些讀操作包括：exists()、getChildren()及getData()。watch事件是一次性的觸發(fā)器，當watch的對象狀態(tài)發(fā)生改變時，將會觸發(fā)此對象上watch所對應的事件。watch事件將被異步地發(fā)送給客戶端，并且ZooKeeper為watch機制提供了有序的一致性保證。理論上，客戶端接收watch事件的時間要快于其看到watch對象狀態(tài)變化的時間。

watch注冊與觸發(fā)

image.png

① exists操作上的watch，在被監(jiān)視的Znode創(chuàng)建、刪除或數據更新時被觸發(fā)。

② getData操作上的watch，在被監(jiān)視的Znode刪除或數據更新時被觸發(fā)。在被創(chuàng)建時不能被觸發(fā)，因為只有Znode一定存在，getData操作才會成功。

③ getChildren操作上的watch，在被監(jiān)視的Znode的子節(jié)點創(chuàng)建或刪除，或是這個Znode自身被刪除時被觸發(fā)。可以通過查看watch事件類型來區(qū)分是Znode，還是他的子節(jié)點被刪除：NodeDelete表示Znode被刪除，NodeDeletedChanged表示子節(jié)點被刪除。

Watch由客戶端所連接的ZooKeeper服務器在本地維護，因此watch可以非常容易地設置、管理和分派。當客戶端連接到一個新的服務器時，任何的會話事件都將可能觸發(fā)watch。另外，當從服務器斷開連接的時候，watch將不會被接收。但是，當一個客戶端重新建立連接的時候，任何先前注冊過的watch都會被重新注冊。

需要注意的幾點

Zookeeper的watch實際上要處理兩類事件：

① 連接狀態(tài)事件(type=None, path=null)

這類事件不需要注冊，也不需要我們連續(xù)觸發(fā)，我們只要處理就行了。

② 節(jié)點事件

節(jié)點的建立，刪除，數據的修改。它是one time trigger，我們需要不停的注冊觸發(fā)，還可能發(fā)生事件丟失的情況。

上面2類事件都在Watch中處理，也就是重載的process(Event event)方法。

節(jié)點事件的觸發(fā)，通過函數exists，getData或getChildren來處理這類函數，有雙重作用：

① 注冊觸發(fā)事件

② 函數本身的功能

函數的本身的功能又可以用異步的回調函數來實現，重載processResult()過程中處理函數本身的功能。

ZooKeeper 會話超時

1、會話概述

在ZooKeeper中，客戶端和服務端建立連接后，會話隨之建立，生成一個全局唯一的會話ID(Session ID)。服務器和客戶端之間維持的是一個長連接，在SESSION_TIMEOUT時間內，服務器會確定客戶端是否正常連接 (客戶端會定時向服務器發(fā)送heart_beat，服務器重置下次SESSION_TIMEOUT時間)。因此，在正常情況下，Session一直有效，并且ZK集群所有機器上都保存這個Session信息。在出現網絡或其它問題情況下（例如客戶端所連接的那臺ZK機器掛了，或是其它原因的網絡閃斷），客戶端與當前連接的那臺服務器之間連接斷了，這個時候客戶端會主動在地址列表（實例化ZK對象的時候傳入構造方法的那個參數connectString）中選擇新的地址進行連接。

2、連接斷開

好了，上面基本就是服務器與客戶端之間維持會話的過程了。在這個過程中，用戶可能會看到兩類異常CONNECTIONLOSS (連接斷開) 和 SESSIONEXPIRED (Session過期)。連接斷開(CONNECTIONLOSS)一般發(fā)生在網絡的閃斷或是客戶端所連接的服務器掛機的時候，這種情況下，ZooKeeper客戶端自己會首先感知到這個異常，具體邏輯是在如下方法中觸發(fā)的：一種場景是Server服務器掛了，這個時候，ZK客戶端首先會捕獲異常。

所以，現在對于“連接斷開”這個過程就一目了然了，核心流程如下：ZK客戶端捕獲“連接斷開”異常 ——> 獲取一個新的ZK地址 ——> 嘗試連接，
在這個流程中，我們可以發(fā)現，整個過程不需要開發(fā)者額外的程序介入，都是ZK客戶端自己會進行的，并且，使用的會話ID都是同一個，所以結論就是：發(fā)生CONNECTIONLOSS的情況，應用不需要做什么事情，等待ZK客戶端建立新的連接即可。

3、會話超時

SESSIONEXPIRED發(fā)生在上面藍色文字部分，這個通常是ZK客戶端與服務器的連接斷了，試圖連接上新的ZK機器，但是這個過程如果耗時過長，超過了SESSION_TIMEOUT 后還沒有成功連接上服務器，那么服務器認為這個Session已經結束了（服務器無法確認是因為其它異常原因還是客戶端主動結束會話），由于在ZK中，很多數據和狀態(tài)都是和會話綁定的，一旦會話失效，那么ZK就開始清除和這個會話有關的信息，包括這個會話創(chuàng)建的臨時節(jié)點和注冊的所有Watcher。在這之后，由于網絡恢復后，客戶端可能會重新連接上服務器，但是很不幸，服務器會告訴客戶端一個異常：SESSIONEXPIRED（會話過期）。此時客戶端的狀態(tài)變成 CLOSED狀態(tài)，應用要做的事情就是的看自己應用的復雜程序了，要重新實例zookeeper對象，然后重新操作所有臨時數據（包括臨時節(jié)點和注冊Watcher），總之，會話超時在ZK使用過程中是真實存在的。

所以這里也簡單總結下，一旦發(fā)生會話超時，那么存儲在ZK上的所有臨時數據與注冊的訂閱者都會被移除，此時需要重新創(chuàng)建一個ZooKeeper客戶端實例，需要自己編碼做一些額外的處理。

4、會話時間（Session Time）

在《ZooKeeper API 使用》一文中已經提到，在實例化一個ZK客戶端的時候，需要設置一個會話的超時時間。這里需要注意的一點是，客戶端并不是可以隨意設置這個會話超時時間，在ZK服務器端對會話超時時間是有限制的，主要是minSessionTimeout和maxSessionTimeout這兩個參數設置的。（詳細查看這個文章《ZooKeeper管理員指南》）Session超時時間限制，如果客戶端設置的超時時間不在這個范圍，那么會被強制設置為最大或最小時間。 默認的Session超時時間是在2 * tickTime ~ 20 * tickTime。所以，如果應用對于這個會話超時時間有特殊的需求的話，一定要和ZK管理員溝通好，確認好服務端是否設置了對會話時間的限制。

ZooKeeper 典型的應用場景

Zookeeper 從設計模式角度來看，是一個基于觀察者設計模式的分布式服務管理框架，它負責存儲和管理大家都關心的數據，然后接受觀察者的注冊，一旦這些數據的狀態(tài)發(fā)生變化，Zookeeper 就將負責通知已經在 Zookeeper 上注冊的那些觀察者做出相應的反應，從而實現集群中類似 Master/Slave 管理模式，關于 Zookeeper 的詳細架構等內部細節(jié)可以閱讀 Zookeeper 的源碼。

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

統一命名服務（Name Service）

分布式應用中，通常需要有一套完整的命名規(guī)則，既能夠產生唯一的名稱又便于人識別和記住，通常情況下用樹形的名稱結構是一個理想的選擇，樹形的名稱結構是一 個有層次的目錄結構，既對人友好又不會重復。說到這里你可能想到了 JNDI，沒錯 Zookeeper 的 Name Service 與 JNDI 能夠完成的功能是差不多的，它們都是將有層次的目錄結構關聯到一定資源上，但是 Zookeeper 的 Name Service 更加是廣泛意義上的關聯，也許你并不需要將名稱關聯到特定資源上，你可能只需要一個不會重復名稱，就像數據庫中產生一個唯一的數字主鍵一樣。

Name Service 已經是 Zookeeper 內置的功能，你只要調用 Zookeeper 的 API 就能實現。如調用 create 接口就可以很容易創(chuàng)建一個目錄節(jié)點。

配置管理（Configuration Management）

配置的管理在分布式應用環(huán)境中很常見，例如同一個應用系統需要多臺 PC Server 運行，但是它們運行的應用系統的某些配置項是相同的，如果要修改這些相同的配置項，那么就必須同時修改每臺運行這個應用系統的 PC Server，這樣非常麻煩而且容易出錯。

像 這樣的配置信息完全可以交給 Zookeeper 來管理，將配置信息保存在 Zookeeper 的某個目錄節(jié)點中，然后將所有需要修改的應用機器監(jiān)控配置信息的狀態(tài)，一旦配置信息發(fā)生變化，每臺應用機器就會收到 Zookeeper 的通知，然后從 Zookeeper 獲取新的配置信息應用到系統中。

image.png

集群管理（Group Membership）

Zookeeper 能夠很容易的實現集群管理的功能，如有多臺 Server 組成一個服務集群，那么必須要一個“總管”知道當前集群中每臺機器的服務狀態(tài)，一旦有機器不能提供服務，集群中其它集群必須知道，從而做出調整重新分配服務策略。同樣當增加集群的服務能力時，就會增加一臺或多臺 Server，同樣也必須讓“總管”知道。

Zookeeper 不僅能夠幫你維護當前的集群中機器的服務狀態(tài)，而且能夠幫你選出一個“總管”，讓這個總管來管理集群，這就是 Zookeeper 的另一個功能 Leader Election。

它們的實現方式都是在 Zookeeper 上創(chuàng)建一個 EPHEMERAL 類型的目錄節(jié)點，然后每個 Server 在它們創(chuàng)建目錄節(jié)點的父目錄節(jié)點上調用 getChildren(String path, boolean watch) 方法并設置 watch 為 true，由于是 EPHEMERAL 目錄節(jié)點，當創(chuàng)建它的 Server 死去，這個目錄節(jié)點也隨之被刪除，所以 Children 將會變化，這時 getChildren上的 Watch 將會被調用，所以其它 Server 就知道已經有某臺 Server 死去了。新增 Server 也是同樣的原理。

Zookeeper 如何實現 Leader Election，也就是選出一個 Master Server。和前面的一樣，每臺 Server 創(chuàng)建一個 EPHEMERAL 目錄節(jié)點，不同的是它還是一個 SEQUENTIAL 目錄節(jié)點，所以它是個 EPHEMERAL_SEQUENTIAL 目錄節(jié)點。之所以它是 EPHEMERAL_SEQUENTIAL 目錄節(jié)點，是因為我們可以給每臺 Server 編號，我們可以選擇當前是最小編號的 Server 為 Master，假如這個最小編號的 Server 死去，由于是 EPHEMERAL 節(jié)點，死去的 Server 對應的節(jié)點也被刪除，所以當前的節(jié)點列表中又出現一個最小編號的節(jié)點，我們就選擇這個節(jié)點為當前 Master。這樣就實現了動態(tài)選擇 Master，避免了傳統意義上單 Master 容易出現單點故障的問題。

image.png

共享鎖（Locks）

共享鎖在同一個進程中很容易實現，但是在跨進程或者在不同 Server 之間就不好實現了。Zookeeper 卻很容易實現這個功能，實現方式也是需要獲得鎖的 Server 創(chuàng)建一個 EPHEMERAL_SEQUENTIAL 目錄節(jié)點，然后調用 getChildren方法獲取當前的目錄節(jié)點列表中最小的目錄節(jié)點是不是就是自己創(chuàng)建的目錄節(jié)點，如果正是自己創(chuàng)建的，那么它就獲得了這個鎖，如果不是那么它就調用 exists(String path, boolean watch) 方法并監(jiān)控 Zookeeper 上目錄節(jié)點列表的變化，一直到自己創(chuàng)建的節(jié)點是列表中最小編號的目錄節(jié)點，從而獲得鎖，釋放鎖很簡單，只要刪除前面它自己所創(chuàng)建的目錄節(jié)點就行了。

image.png

同步鎖的關鍵代碼：

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 實現的實現思路如下：

創(chuàng)建一個父目錄 /synchronizing，每個成員都監(jiān)控標志位目錄 /synchronizing/start 是否存在，然后每個成員都加入這個隊列，加入隊列的方式就是創(chuàng)建 /synchronizing/member_i 的臨時目錄節(jié)點，然后每個成員獲取 /synchronizing 目錄的所有目錄節(jié)點，也就是 member_i。判斷 i 的值是否已經是成員的個數，如果小于成員個數等待 /synchronizing/start 的出現，如果已經相等就創(chuàng)建 /synchronizing/start。

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

image.png

同步隊列的關鍵代碼如下：

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 實現思路如下：

實現的思路也非常簡單，就是在特定的目錄下創(chuàng)建 SEQUENTIAL 類型的子目錄 /queue_i，這樣就能保證所有成員加入隊列時都是有編號的，出隊列時通過 getChildren( ) 方法可以返回當前所有的隊列中的元素，然后消費其中最小的一個，這樣就能保證 FIFO。

下面是生產者和消費者這種隊列形式的示例代碼：

生產者代碼：

 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; 
}

消費者代碼：

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 之間狀態(tài)同步等。

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