ZooKeeper的架構

看看下面的圖表。它描述了ZooKeeper的“客戶端-服務器架構”。

作為ZooKeeper架構的一部分的每個組件在下表中進行了說明。

層次命名空間

下圖描述了用於內存表示的ZooKeeper文件系統的樹結構。ZooKeeper節點稱為 znode 。每個znode由一個名稱標識，並用路徑(/)序列分隔。

• 在圖中，首先有一個由“/”分隔的znode。在根目錄下，你有兩個邏輯命名空間 config 和 workers 。

• config 命名空間用於集中式配置管理，workers

  命名空間用於命名。

• 在 config 命名空間下，每個znode最多可存儲1MB的數據。這與UNIX文件系統相類似，除了父znode也可以存儲數據。這種結構的主要目的是存儲同步數據並描述znode的元數據。此結構稱為 ZooKeeper數據模型。

ZooKeeper數據模型中的每個znode都維護著一個 stat 結構。一個stat僅提供一個znode的元數據。它由版本號，操作控制列表(ACL)，時間戳和數據長度組成。

• 版本號 - 每個znode都有版本號，這意味著每當與znode相關聯的數據發生變化時，其對應的版本號也會增加。當多個zookeeper客戶端嘗試在同一znode上執行操作時，版本號的使用就很重要。

• 操作控制列表(ACL) - ACL基本上是訪問znode的認證機制。它管理所有znode讀取和寫入操作。

• 時間戳 - 時間戳表示創建和修改znode所經過的時間。它通常以毫秒為單位。ZooKeeper從“事務ID"(zxid)標識znode的每個更改。Zxid 是唯一的，並且為每個事務保留時間，以便你可以輕松地確定從一個請求到另一個請求所經過的時間。

• 數據長度 - 存儲在znode中的數據總量是數據長度。你最多可以存儲1MB的數據。

Znode的類型

Znode被分為持久（persistent）節點，順序（sequential）節點和臨時（ephemeral）節點。

• 持久節點 - 即使在創建該特定znode的客戶端斷開連接後，持久節點仍然存在。默認情況下，除非另有說明，否則所有znode都是持久的。

• 臨時節點 - 客戶端活躍時，臨時節點就是有效的。當客戶端與ZooKeeper集合斷開連接時，臨時節點會自動刪除。因此，只有臨時節點不允許有子節點。如果臨時節點被刪除，則下一個合適的節點將填充其位置。臨時節點在leader選舉中起著重要作用。

• 順序節點 - 順序節點可以是持久的或臨時的。當一個新的znode被創建為一個順序節點時，ZooKeeper通過將10位的序列號附加到原始名稱來設置znode的路徑。例如，如果將具有路徑 /myapp 的znode創建為順序節點，則ZooKeeper會將路徑更改為 /myapp0000000001 ，並將下一個序列號設置為0000000002。如果兩個順序節點是同時創建的，那麽ZooKeeper不會對每個znode使用相同的數字。順序節點在鎖定和同步中起重要作用。

Sessions（會話）

會話對於ZooKeeper的操作非常重要。會話中的請求按FIFO順序執行。一旦客戶端連接到服務器，將建立會話並向客戶端分配會話ID 。

客戶端以特定的時間間隔發送心跳以保持會話有效。如果ZooKeeper集合在超過服務器開啟時指定的期間（會話超時）都沒有從客戶端接收到心跳，則它會判定客戶端死機。

會話超時通常以毫秒為單位。當會話由於任何原因結束時，在該會話期間創建的臨時節點也會被刪除。

Watches（監視）

監視是一種簡單的機制，使客戶端收到關於ZooKeeper集合中的更改的通知。客戶端可以在讀取特定znode時設置Watches。Watches會向註冊的客戶端發送任何znode（客戶端註冊表）更改的通知。

Znode更改是與znode相關的數據的修改或znode的子項中的更改。只觸發一次watches。如果客戶端想要再次通知，則必須通過另一個讀取操作來完成。當連接會話過期時，客戶端將與服務器斷開連接，相關的watches也將被刪除。

ZooKeeper的架構