Hadoop大資料實戰系列文章之Zookeeper

Zookeeper 是一種分散式的，開源的，應用於分散式應用的協作服務。它提供了一些簡單的操作，使得分散式應用可以基於這些介面實現諸如同步、配置維護和分叢集或者命名的服務。Zookeeper 很容易程式設計接入，它使用了一個和檔案樹結構相似的資料模型。可以使用 Java 或者 C 來進行程式設計接入。

眾所周知，分散式的系統協作服務很難有讓人滿意的產品。這些協作服務產品很容易陷入一些諸如競爭選擇條件或者死鎖的陷阱中。Zookeeper的目的就是將分散式服務不再需要由於協作衝突而另外實現協作服務。

本章內容：

1) Zookeeper 資料模型

2) Zookeeper 訪問控制

3) Zookeeper 應用場景

1. Zookeeper 資料模型

ZooKeeper 擁有一個層次的名稱空間，這個和標準的檔案系統非常相似

從圖中我們可以看出ZooKeeper的資料模型，在結構上和標準檔案系統的非常相似，都是採用這種樹形層次結構，ZooKeeper樹中的每個節點被稱為—Znode。和檔案系統的目錄樹一樣，ZooKeeper 樹中的每個節點可以擁有子節點。但也有不同之處：

1) 引用方式:

Zonde 透過路徑引用，如同 Unix 中的檔案路徑。路徑必須是絕對的，因此他們必須由斜槓字元來開頭。除此以外，他們必須是唯一的，也就是說每一個路徑只有一個表示，因此這些路徑不能改變。在 ZooKeeper 中，路徑由 Unicode 字串組成，並且有一些限制。字串"/zookeeper"用以儲存管理資訊，比如關鍵配額資訊。

2) Znode 結構

ZooKeeper名稱空間中的Znode，兼具檔案和目錄兩種特點。既像檔案一樣維護著資料、元資訊、ACL、時間戳等資料結構，又像目錄一樣可以作為路徑標識的一部分。圖中的每個節點稱為一個 Znode。 每個 Znode 由 3 部分組成:

 stat：此為狀態資訊, 描述該 Znode 的版本, 許可權等資訊

 data：與該 Znode 關聯的資料

 children：該 Znode 下的子節點

ZooKeeper雖然可以關聯一些資料，但並沒有被設計為常規的資料庫或者大資料儲存，相反的是，它用來管理排程資料，比如分散式應用中的配置檔案資訊、狀態資訊、彙集位置等等。這些資料的共同特性就是它們都是很小的資料，通常以 KB 為大小單位。ZooKeeper的伺服器和客戶端都被設計為嚴格檢查並限制每個Znode的資料大小至多1M，但常規使用中應該遠小於此值。

3) 資料訪問

ZooKeeper中的每個節點儲存的資料要被原子性的操作。也就是說讀操作將獲取與節點相關的所有資料，寫操作也將替換掉節點的所有資料。另外，每一個節點都擁有自己的ACL(訪問控制列表)，這個列表規定了使用者的許可權，即限定了特定使用者對目標節點可以執行的操作。

4) 節點型別

Persistent Nodes：永久有效地節點,除非client 顯式的刪除,否則一直存在。

Ephemeral Nodes：臨時節點,僅在建立該節點 client 保持連線期間有效,一旦連線丟

失,zookeeper 會自動刪除該節點。

Sequence Nodes：順序節點,client 申請建立該節點時, ZooKeeper 會自動在節點路徑末尾新增遞增序號,這種型別是實現分散式鎖,分散式 queue 等特殊功能的關鍵。

5) 監控

客戶端可以在節點上設定 watch，我們稱之為監視器。當節點狀態發生改變時(Znode的增、刪、改)將會觸發 watch 所對應的操作。當 watch 被觸發時，ZooKeeper 將會向客戶端傳送且僅傳送一條通知，因為 watch 只能被觸發一次，這樣可以減少網路流量。

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

2. Zookeeper 問 訪問 控制

傳統的檔案系統中，ACL 分為兩個維度，一個是屬組，一個是許可權，子目錄/檔案預設繼承父目錄的 ACL。而在 Zookeeper 中，node 的 ACL 是沒有繼承關係的，是獨立控制的。Zookeeper 的 ACL，可以從三個維度來理解：一是 scheme; 二是 user; 三是permission，通常表示為 scheme:id:permissions, 下面從這三個方面分別來介紹：

1) scheme: scheme 對應於採用哪種方案來進行許可權管理，zookeeper實現了一個pluggable 的 ACL 方案，可以透過擴充套件 scheme，來擴充套件 ACL 的機制。

2) User：與 scheme 是緊密相關的，具體的情況在上面介紹 scheme 的過程都已介紹，這裡不再贅述。

3) permission: zookeeper 目前支援下面一些許可權：

3. Zookeeper 用 應用 場景

1) 資料釋出與訂閱（配置中心）

釋出與訂閱模型，即所謂的配置中心，顧名思義就是釋出者將資料釋出到ZK節點上，供訂閱者動態獲取資料，實現配置資訊的集中式管理和動態更新。例如全域性的配置資訊，服務式服務框架的服務地址列表等就非常適合使用。

2) 分散式鎖服務

分散式鎖，這個主要得益於ZooKeeper為我們保證了資料的強一致性。鎖服務可以分為兩類，一個是保持獨佔，另一個是控制時序。

3) 分散式佇列

佇列方面，簡單地講有兩種，一種是常規的先進先出佇列，另一種是要等到佇列成員聚齊之後的才統一按序執行。對於第一種先進先出佇列，和分散式鎖服務中的控制時序場景基本原理一致，這裡不再贅述。 第二種佇列其實是在FIFO佇列的基礎上作了一個增強。通常可以在 /queue 這個 znode 下預先建立一個/queue/num 節點，並且賦值為 n（或者直接給/queue 賦值n），表示佇列大小，之後每次有佇列成員加入後，就判斷下是否已經到達佇列大小，決定是否可以開始執行了。這種用法的典型場景是，分散式環境中，一個大任務Task A，需要在很多子任務完成（或條件就緒）情況下才能進行。這個時候，凡是其中一個子 任 務 完 成 （ 就 緒 ）， 那 麼 就 去 /taskList 下 建 立 自 己 的 臨 時 時 序 節 點（CreateMode.EPHEMERAL_SEQUENTIAL），當 /taskList 發現自己下面的子節點滿足指定個數，就可以進行下一步按序進行處理了。