一、ZooKeeper 資料模型

ZooKeeper 的資料模型是層次模型(Google Chubby 也是這麼做的)。層次模型常見於檔案 系統。層次模型和 key-value 模型是兩種主流的 資料模型。ZooKeeper 使用檔案系統模型主要基 於以下兩點考慮:   1. 檔案系統的樹形結構便於表達資料之間的層 次關係。

2. 檔案系統的樹形結構便於為不同的應用分配 獨立的名稱空間(namespace)。

ZooKeeper 的層次模型稱作 data tree。Data tree 的每個節點叫作 znode。不同於檔案系統，每個 節點都可以儲存資料。每個節點都有一個版本 (version)。版本從 0 開始計數。

data tree 示例 

在右圖所示的 data tree 中有兩個子樹， 一個用於應用1(/app1)和另一個用於 應用2(/app2)。 

應用1的子樹實現了一個簡單的組成員協議:每個客戶端程序 p 建立一個 znode p_i 在 /app1 下，只要 /app1/p_i存在就代表程序 p 在正常執行。 

data tree 介面 

ZooKeeper 對外提供一個用來訪問 data tree 的簡化檔案系統 API:
• 使用UNIX風格的路徑名來定位znode,例如/A/X表示znodeA的子節點X。
• znode的資料只支援全量寫入和讀取，沒有像通用檔案系統那樣支援部分寫入和讀取。
• datatree的所有API都是wait-free的，正在執行中的API呼叫不會影響其他API的完成。

• datatree的API都是對檔案系統的wait-free操作，不直接提供鎖這樣的分散式協同機制。但 是 data tree 的 API 非常強大，可以用來實現多種分散式協同機制。 

二、znode的分類

一個 znode 可以使永續性的，也可以是臨時性的:

1. 永續性的 znode (PERSISTENT): ZooKeeper 宕機，或者 client 宕機，這個 znode 一旦建立就不會丟失。

2. 臨時性的 znode (EPHEMERAL): ZooKeeper 宕機了，或者 client 在指定的 timeout 時間內沒有連線 server ，都會被認為丟失。

znode 節點也可以是順序性的。每一個順序性的 znode 關聯一個唯一的單調遞增整數。這個單調遞增整 數是 znode 名字的字尾。如果上面兩種 znode 如果具備順序性，又有以下兩種 znode:

3. 持久順序性的 znode(PERSISTENT_SEQUENTIAL): znode 除了具備永續性 znode 的特點之外，znode 的 名字具備順序性。

4. 臨時順序性的 znode(EPHEMERAL_SEQUENTIAL): znode 除了具備臨時性 znode 的特點之外，znode 的名字具備順序性。

ZooKeeper 主要有以上 4 種 znode。 

三、Zookeeper總體架構

應用使用 ZooKeeper 客戶端庫使用 ZooKeeper 服務。 ZooKeeper 客戶端負責和 ZooKeeper叢集的互動。 ZooKeeper 叢集可以有兩種模式:standalone模式和 quorum模式。處於standalone 模式的 ZooKeeper 叢集還有一個獨立執行的 ZooKeeper 節點。處於 quorum模式的 ZooKeeper 叢集包換多 個 ZooKeeper 節點。 

 1. Session

ZooKeeper 客戶端庫和 ZooKeeper 叢集中的節點建立一個 session。客戶端可以主動關閉 session。另外如果ZooKeeper 節點沒有在 session 關聯的 timeout 時間內收到客戶端的資料的話， ZooKeeper 節點也會關閉session。另外 ZooKeeper 客戶端庫如果發現連線的 ZooKeeper 出錯，會自動的和其他 ZooKeeper 節點建立連線。 

 2. Quorum 模式 

處於 Quorum模式的 ZooKeeper 叢集包含多個 ZooKeeper 節點。 下圖的 ZooKeeper 叢集有 3 個 節點，其中節點 1 是 leader 節點，節點 2 和節點 3 是 follower 節點。 leader 節點可以處理讀寫 請求，follower 只可以處理讀請求。 follower 在接到寫請求時會把寫請求轉發給leader來處理。 

3. 資料一致性 

 • 可線性化(Linearizable)寫入:先到達 leader 的寫請求會被先處理，leader 決定寫請求的執 行順序。

• 客戶端FIFO順序:來自給定客戶端的請求按照發送順序執行。