什么是ZooKeeper數據模型

什么是ZooKeeper數據模型？很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

1、數據結構圖

圖中的每個節點稱為一個 Znode。 每個 Znode 由 3 部分組成:

（1）stat：此為狀態信息, 描述該 Znode 的版本, 權限等信息

（2）data：與該 Znode 關聯的數據

（3）children：該 Znode 下的子節點

2、節點類型

Znode有兩種，分別為臨時節點和永久節點。節點的類型在創建時即被確定，并且不能改變。臨時節點：該節點的生命周期依賴于創建它們的會話。一旦會話結束，臨時節點將被自動刪除，當然可以也可以手動刪除。臨時節點不允許擁有子節點。永久節點：該節點的生命周期不依賴于會話，并且只有在客戶端顯示執行刪除操作的時候，他們才能被刪除。

Znode還有一個序列化的特性，如果創建的時候指定的話，該 Znode 的名字后面會自動追加一個不斷增加的序列號。序列號對于此節點的父節點來說是唯一的，這樣便會記錄每個子節點創建的先后順序。它的格式為“%10d”(10位數字，沒有數值的數位用 0 補充，例如“0000000001”)。

3、節點屬性

每個 znode 都包含了一系列的屬性，通過命令 get，可以獲得節點的屬性。

dataVersion：數據版本號，每次對節點進行 set 操作，dataVersion 的值都會增加 1（即使設置的是相同的數據），可有效避免了數據更新時出現的先后順序問題。

cversion ：子節點的版本號。當 znode 的子節點有變化時，cversion 的值就會增加 1。

cZxid ：Znode 創建的事務 id。

mZxid ：Znode 被修改的事務 id，即每次對 znode 的修改都會更新 mZxid。對于 zk 來說，每次的變化都會產生一個唯一的事務 id，zxid（ZooKeeper Transaction Id）。通過 zxid，可以確定更新操作的先后順序。例如，如果 zxid1小于 zxid2，說明 zxid1 操作先于 zxid2 發生，zxid 對于整個 zk 都是唯一的， 即使操作的是不同的 znode。

ctime：節點創建時的時間戳。

mtime：節點最新一次更新發生時的時間戳。          

ephemeralOwner：如果該節點為臨時節點，ephemeralOwner 值表示與該節點。綁定的 session id。如果不是，ephemeralOwner 值為 0。

在 client 和 server 通信之前，首先需要建立連接，該連接稱為 session。連接建立后，如果發生連接超時、授權失敗，或者顯式關閉連接，連接便處于 CLOSED 狀態，此時 session 結束。

4、ZooKeeper Watcher（監聽機制）

ZooKeeper 提供了分布式數據發布/訂閱功能，一個典型的發布/訂閱模型系統定義了一種一對多的訂閱關系，能讓多個訂閱者同時監聽某一個主題對象，當這個主題對象自身狀態變化時，會通知所有訂閱者，使他們能夠做出相應的處理。 ZooKeeper 中，引入了 Watcher 機制來實現這種分布式的通知功能。ZooKeeper 允許客戶端向服務端注冊一個 Watcher 監聽，當服務端的一些事件觸發了這個 Watcher，那么就會向指定客戶端發送一個事件通知來實現分布式的通知功能。觸發事件種類很多，如：節點創建，節點刪除，節點改變，子節點改變等?？偟膩碚f可以概括 Watcher 為以下三個過程：客戶端向服務端注冊 Watcher、服務端事件發生觸發 Watcher、客戶端回調 Watcher 得到觸發事件情況

（1）Watch 機制特點

一次性觸發：事件發生觸發監聽，一個 watcher event 就會被發送到設置監聽的客戶端， 這種效果是一次性的，后續再次發生同樣的事件，不會再次觸發。

事件封裝：ZooKeeper 使用 WatchedEvent 對象來封裝服務端事件并傳遞。WatchedEvent 包含了每一個事件的三個基本屬性：通知狀態（keeperState），事件類型（EventType）和節點路徑（path）。

event 異步發送：watcher 的通知事件從服務端發送到客戶端是異步的。先注冊再觸發 Zookeeper 中的 watch 機制，必須客戶端先去服務端注冊監聽，這樣事件發送才會觸發監聽，通知給客戶端。

（2）通知狀態和事件類型

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。