在ZooKeeper的實際使用中，我們的做法往往是搭建一個共用的ZooKeeper叢集，統一為若干個應用提供服務。在這種情況下，不同的應用往往是不會存在共享資料的使用場景的，因此需要解決不同應用之間的許可權問題。

        為了避免儲存在ZooKeeper伺服器上的資料被其他程序干擾或人為操作修改，需要對ZooKeeper上的資料訪問進行許可權控制（Access Control）。ZooKeeper提供了ACL的許可權控制機制，簡單的講，就是通過設定ZooKeeper伺服器上資料節點的ACL，來控制客戶端對該資料節點的訪問許可權：如果iyge客戶端符合該ACL控制，那麼就可以對其進行訪問，否則將無法操作。針對這樣的控制機制，ZooKeeper提供了多種許可權控制模式（Scheme），分別是world、auth、digest、ip和super。這裡主要是在digest模式下如何進行ZooKeeper的許可權控制。

        開發人員如果要使用ZooKeeper的許可權控制功能，需要在完成ZooKeeper會話建立後，給該會話新增上相關的許可權資訊（AuthInfo）。ZooKeeper客戶端提供了相應的API介面來進行許可權資訊的設定，如下：

addAuthInfo(String scheme, byte[] auth)

API方法的引數說明如下表所示。

引數名	說明
scheme	許可權控制模式，分為world、auth、digest、ip和super
auth	具體的許可權資訊

        該介面主要用於為當前ZooKeeper會話新增許可權資訊，之後凡是通過該會話對ZooKeeper服務端進行的任何操作，都會帶上該許可權資訊。

使用包含許可權資訊的ZooKeeper會話建立資料節點

public class AuthSample {

final static String PATH = "/zk-book-auth_test";

public static void main(String[] args) throws Exception {

ZooKeeper zookeeper = new ZooKeeper("domain1.book.zookeeper:2181", 50000, null);

zookeeper.addAuthInfo("digest", "foo:true".getBytes());

zookeeper.create(PATH, "init".getBytes(), Ids.CREATOR_ALL_ACL, CreateMode.EPHEMERAL);

Thread.sleep(Integer.MAX_VALUE);

}

}

        上面這個示例程式就是一個典型的對ZooKeeper會話新增許可權資訊的使用方式。在這個示例中，我們採用了digest模式，同時可以看到其包含的具體許可權資訊是foo:true，這非常類似於username:password的格式。完成許可權資訊的新增後，該示例還使用客戶端會話在ZooKeeper上建立了/zk-book-auth-test節點，這樣該節點就受到了許可權控制。下面我們來看，針對這個資料節點，ZooKeeper是如何進行許可權控制的。

使用無許可權資訊的ZooKeeper會話訪問含許可權資訊的資料節點

public class AuthSample_Get {

final static String PATH = "/zk-book-auth_test";

public static void main(String[] args) throws Exception {

ZooKeeper zookeeper1 = new ZooKeeper("domain1.book.zookeeper:2181", 50000, null);

zookeeper1.addAuthInfo("digest", "foo:true".getBytes());

zookeeper1.create(PATH, "init".getBytes(), Ids.CREATOR_ALL_ACL, CreateMode.EPHEMERAL);

ZooKeeper zookeeper2 = new ZooKeeper("domain1.book.zookeeper:2181", 50000, null);

zookeeper2.getData(PATH, false, null);

}

        執行程式，輸出異常資訊如下：

        在上面這個示例程式中，我們首先通過一個包含許可權資訊的客戶端會話建立了一個數據節點，然後使用另一個不包含許可權資訊的客戶端會話對其進行訪問，執行程式後，輸出了異常資訊：KeeperErrorCode = NoAuth for /zk-book-auth_test。可見，一旦我們對一個數據節點設定了許可權資訊，那麼其他沒有許可權設定的客戶端會話將無法訪問該資料節點。ZooKeeper服務端能夠為我們實現許可權控制。

使用錯誤許可權資訊的ZooKeeper會話訪問含許可權資訊的資料節點

// 使用錯誤許可權資訊的ZooKeeper會話訪問含許可權資訊的資料節點

public class AuthSample_Get2 {

final static String PATH = "/zk-book-auth_test";

public static void main(String[] args) throws Exception {

ZooKeeper zookeeper1 = new ZooKeeper("domain1.book.zookeeper:2181", 50000, null);

zookeeper1.addAuthInfo("digest", "foo:true".getBytes());

zookeeper1.create(PATH, "init".getBytes(), Ids.CREATOR_ALL_ACL, CreateMode.EPHEMERAL);

ZooKeeper zookeeper2 = new ZooKeeper("domain1.book.zookeeper:2181", 50000, null);

zookeeper2.addAuthInfo("digest", "foo:true".getBytes());
System.out.println(zookeeper2.getData(PATH, false, null ));

ZooKeeper zookeeper3 = new ZooKeeper("domain1.book.zookeeper:2181", 50000, null);

zookeeper3.addAuthInfo("digest", "foo:false".getBytes());

zookeeper3.getData(PATH, false, null);

}

        執行程式，輸出結果如下：

        在上面這個示例程式中，我們同樣使用包含許可權資訊的客戶端會話建立了資料節點，同時使用了兩個許可權資訊，先後進行了兩次資料節點內容的獲取。第一次，我們使用了正確的許可權資訊，即digest[foo:true]，同時也成功獲取到了資料節點的資料內容：[[email protected]；而在第二次介面呼叫中，由於使用了錯誤的許可權資訊，即digest[foo:false]，結果出現異常：KeeperErrorCode = NoAuth for /zk-book-auth_test。可見，ZooKeeper的許可權控制也能夠為我們識別出錯誤的許可權資訊。

        在ZooKeeper中，幾乎所有的API介面操作，其許可權控制策略都是和上面幾個示例類似的，但是對於刪除節點（delete）介面而言，其許可權控制比較特殊。

刪除節點介面的許可權控制

// 刪除節點介面的許可權控制

public class AuthSample_Delete {

final static String PATH = "/zk-book-auth_test";

final static String PATH2 = "/zk-book-auth_test/child";

public static void main(String[] args) throws Exception {

ZooKeeper zookeeper1 = new ZooKeeper("domain1.book.zookeeper:2181", 50000, null);

zookeeper1.addAuthInfo("digest", "foo:true".getBytes());

zookeeper1.create(PATH, "init".getBytes(), Ids.CREATOR_ALL_ACL, CreateMode.PERSISTENT);

zookeeper1.create(PATH2, "init".getBytes(), Ids.CREATOR_ALL_ACL, CreateMode.EPHEMERAL);

try {

ZooKeeper zookeeper2 = new ZooKeeper("domain1.book.zookeeper:2181", 50000, null);
zookeeper2.delete(PATH2, -1);

} catch (Exception e) {

System.out.println("刪除節點失敗：" + e.getMessage());

}
ZooKeeper zookeeper3 = new ZooKeeper("domain1.book.zookeeper:2181", 50000, null);
zookeeper3.addAuthInfo("digest", "foo:true".getBytes());
zookeeper3.delete(PATH2, -1);
System.out.println("成功刪除節點：" + PATH2);

ZooKeeper zookeeper4 = new ZooKeeper("domain1.book.zookeeper:2181", 50000, null);
zookeeper4.delete(PATH, -1);
System.out.println("成功刪除節點：" + PATH);

}

        執行程式，輸出結果如下：

         在上面這個示例程式中，第一次，我們使用沒有包含許可權資訊的客戶端會話進行資料節點刪除操作，顯然，程式執行程式中丟擲了異常資訊：KeeperErrorCode = NoAuth for /zk-book-auth_test/child。而在第二次介面呼叫中，由於使用了正確的許可權資訊，因此成功刪除了資料節點，相信這也不難理解。

        下面我們著重來看第三次節點刪除操作。需要注意的是，在這次刪除操作中，我們使用的是沒有包含許可權資訊的客戶端會話，但最終卻成功刪除了資料節點。從這個例子中，我們可以看到，刪除節點介面的許可權控制比較特殊，當客戶端對一個數據節點添加了許可權資訊後，對於刪除操作而言，其作用範圍是其子節點。也就是說，當我們對一個數據節點新增資訊後，依然可以自由的刪除這個節點，但是對於這個節點的子節點，就必須使用相應的許可權資訊才能夠刪除掉他。