很多負載均衡架構和微服務架構將Zookeeper做為註冊中心來使用。今天我們來聊一聊zookeeper的數據結構，看看zookeeper做為註冊中心時是怎麼保存各個微服務信息的。
zookeeper集群自身維護了一套數據結構。這個存儲結構是一個樹形結構，其上的每一個節點，我們稱之為“znode”。如下所示：
Ø 每一個znode默認能夠存儲1MB的數據（對於記錄狀態性質的數據來說，夠了）
Ø 可以使用zkCli命令，登錄到zookeeper上，並通過ls、create、delete、sync等命令操作這些znode節點
Ø znode除了名稱、數據以外，還有一套屬性：zxid。這套zid與時間戳對應，記錄zid不同的狀態（後續我們將用到）
那麼每個znode結構又是什麼樣的呢？如下圖所示：
此外，znode還有操作權限。如果我們把以上幾類屬性細化，又可以得到以下屬性的細節：
Ø czxid：創建節點的事務的zxid
Ø mzxid：對znode最近修改的zxid
Ø ctime：以距離時間原點(epoch)的毫秒數表示的znode創建時間
Ø mtime：以距離時間原點(epoch)的毫秒數表示的znode最近修改時間
Ø version：znode數據的修改次數
Ø cversion：znode子節點修改次數
Ø aversion：znode的ACL修改次數
Ø ephemeralOwner：如果znode是臨時節點，則指示節點所有者的會話ID；如果不是臨時節點，則為零。
Ø dataLength：znode數據長度。
Ø numChildren：znode子節點個數。
znode中的存在類型
我們知道了zookeeper內部維護了一套數據結構：由znode構成的集合，znode的集合又是一個樹形結構。每一個znode又有很多屬性進行描述。並且znode的存在性還分為四類，如下如所示：
znode是由客戶端創建的，它和創建它的客戶端的內在聯繫，決定了它的存在性：
Ø PERSISTENT-持久化節點：創建這個節點的客戶端在與zookeeper服務的連接斷開後，這個節點也不會被刪除（除非您使用API強制刪除）。
Ø PERSISTENT_SEQUENTIAL-持久化順序編號節點：當客戶端請求創建這個節點A後，zookeeper會根據parent-znode的zxid狀態，為這個A節點編寫一個全目錄唯一的編號（這個編號只會一直增長）。當客戶端與zookeeper服務的連接斷開後，這個節點也不會被刪除。
Ø EPHEMERAL-臨時目錄節點：創建這個節點的客戶端在與zookeeper服務的連接斷開後，這個節點（還有涉及到的子節點）就會被刪除。
Ø EPHEMERAL_SEQUENTIAL-臨時順序編號目錄節點：當客戶端請求創建這個節點A後，zookeeper會根據parent-znode的zxid狀態，為這個A節點編寫一個全目錄唯一的編號（這個編號只會一直增長）。當創建這個節點的客戶端與zookeeper服務的連接斷開後，這個節點被刪除。
另外，無論是EPHEMERAL還是EPHEMERAL_SEQUENTIAL節點類型，在zookeeper的client異常終止後，節點也會被刪除。
閱讀更多 HelloWorld應用 的文章
