數據模型和分層的命名空間
Zookeeper提供的命名空間非常像一個標准的文件系統。一個名字是一系列的以'/'隔開的一個路徑元素。Zookeeper命名空間中所有的節點都是通過路徑識別。
節點和臨時節點
不像標准的文件系統，Zookeeper命名空間中的每個節點可以有數據也可以有子目錄。它就像一個既可以是文件也可以是目錄的文件系統。(Zookeeper被設計成保存協調數據：狀態信息，配置，位置信息，等等，所以每個節點存儲的數據通常較小，通常在1個字節到數千字節的范圍之內)我們使用術語znode來表明Zookeeper的數據節點。
znode維持了一個stat結構，它包括數據變化的版本號、訪問控制列表變化、和時間戳，允許緩存驗證和協調更新。每當znode的數據有變化，版本號就會增加。例如，每當客戶端檢索數據時同時它也獲取數據的版本信息。版本號和時間戳一起，可讓Zookeeper驗證緩存和協調更新。每次znode的數據發生了變化，版本號就增加。例如，無論何時客戶端檢索數據，它也一起檢索數據的版本號。並且當客戶端執行更新或刪除時，客戶端必須提供他正在改變的znode的版本號。如果它提供的版本號和真實的數據版本號不一致，更新將會失敗。(這種行為可以被覆蓋)
命名空間中每個znode存儲的數據自動的讀取和寫入的，讀取時獲得znode所有關聯的數據字節，寫入時替換所有的數據。每個節點都有一個訪問控制列表來制約誰可以做什么。
Zookeeper還有一個臨時節點的概念。這些znode和session存活的一樣長，session創建時存活，當session結束，也跟着刪除。
Zookeeper還有一個序列節點的概念。當創建znode的時候你還可以請求在路徑的最后追加一個單調遞增的計數器。這個計數器在父節點是唯一的。計數器有一個%010d --的格式，它是10位數用0做填充(計數器用這個方法格式化簡化排序)，也就是：0000000001。查看Queue Recipe使用這個特性的例子。注釋：計數器的序列號由父節點通過一個int類型維護，計數器當超過2147483647的時候將會溢出(-2147483647將會導致)。
在分布式應用工程中，node可以指的是一般的主機，一個服務器，全體成員的一員，一個客戶端程序，等等。在Zookeeper的文檔中，znode指的是數據節點。Servers指的是組成Zookeeper服務的機器；quorum peers 指的是組成全體的servers；client指的是任何使用Zookeeper服務的主機和程序。
Zookeeper里的計時
Zookeeper通過多種方式追蹤計時：
Zxid
每個Zookeeper狀態的變化都以zxid(事務ID)的形式接收到標記。這個暴露了Zookeeper所有變化的總排序。每個變化都會有一個zxid，並且如果zxid1早於zxid2則zxid1一定小於zxid2。
zookeeper中，每一次對數據節點的寫操作，都被認為是一次事務，每一事務，系統都會分配一個事務id(zxid)來標識這個事務
版本號
節點的每個變化都會引起那個節點的版本號的其中之一增加。這三個版本號是version(znode的數據變化版本號),cversion(子目錄的變化版本號)，和aversion(訪問控制列表的變化版本號)。
Ticks
當使用多服務器的Zookeeper時，服務器使用ticks定義事件的時間，如狀態上傳，會話超時，同事之間的連接超時等等。tick次數只是通過最小的會話超時間接的暴露；如果一個客戶端請求會話超時小於最小的會話超時，服務器就會告訴客戶端會話超時實際上是最低會話超時時間。
Real time
Zookeeper不使用實時或時鍾時間，除了將時間戳加在znode創建和更新的stat結構上。
Zookeeper Stat 結構
Zookeeper中的每個znode的stat機構都由下面的字段組成：
- czxid - 引起這個znode創建的zxid (括號內是我自己的理解 create zxid)
- mzxid - znode最后更新的zxid (modify zxid)
- ctime - znode被創建的毫秒數 -從1970年開始)
- mtime - znode最后修改的毫秒數 -從1970年開始)
- version - znode數據變化號
- cversion - znode子節點變化號 (change version)
- aversion - znode訪問控制列表的變化號 (access version)
- ephemeralOwner - 如果是臨時節點這個是znode擁有者的session id。如果不是臨時節點則是0。
- dataLength - znode的數據長度
- numChildren - znode子節點數量
下面正式開始介紹zkCli.sh的使用
1.首先啟動zk
bin/zkServer.sh start
2.建立連接
./zkCli.sh -timeout 0 -server ip:port
- timeout 會話的超時時間，如果服務器在這個timeout規定的時間范圍內，沒有收到心跳包，就認為失效了
./zkCli.sh -timeout 5000 -server 192.168.142.128:2181
出現如上圖說明連接成功。
輸入 h 查詢所有的命令：
創建znode節點命令
其中 -e表示當前節點是臨時節點,-s表示當前節點是序列節點。
我們創建一個基本節點
- ls指令
要查詢是否創建成功，可以使用查詢命令ls / 其中/代表根節點
結果如下：
只輸出了[zookeeper]說明剛才那個節點沒有新建成功，檢查一下。原來是忘了輸入關聯的數據(囧)
再輸入一次：
后面的5就是關聯的數據
如果 新建成功，也會打印出 ‘Created /node_1 ’
現在node_1新建成功了。
查詢znode節點命令
- get指令
通過get命令檢測數據是否與znode關聯上了(數據就是我上面輸入的5)
顯示如下：
第二行的5就是關聯的數據，下面的一些字段的含義可以參照前文的 Zookeeper Stat 結構
-
pZxid 指該節點子節點列表最后一次被修改的事務id。為當前節點添加子節點和刪除子節點會引起子節點列表發生改變，而修改子節點的數據內容是不包括在內的。
-
aclVersion 是指權限版本號
-
stat 指令
還有一個命令類似，查看當前節點的狀態信息，但是不能顯示當前節點數據的值。如下：
為node_1創建兩個子節點：
- ls2 指令
ls2指令是ls指定的加強版，除了可以列出當前節點的所有子節點，還可以輸出當前節點的狀態信息。
修改znode的命令
其中path是需要修改的節點的路徑
data是需要修改成什么樣的值
可選的version是版本號 我們先不輸入版本號
注意到此時dataVersion是2(因為本人已經修改過一次了，這次屬於第二次修改)
get一下
我們再修改一次，然后再get
我們可以發現，版本號自動加了1，說明每次修改節點，節點的版本號會增加。
然后 我們修改時加上版本號 再試一下
版本號先設為當前版本號：
發現修改成功，版本號也加了1
再設一次，此次將版本號還是設為3(dataVersion中已經是4了)，然后查看結果：
提示版本號無效
刪除相關指令
我們試着刪除node_1
提示很明顯,delete指令不能刪除含有子節點的節點，如果要刪除含有子節點的節點，則需要使用命令rmr
刪除后，無錯誤信息，說明刪除成功，通過查看命令驗證一下：
參考：
1.Zookeeper簡介 http://zookeeper.majunwei.com/document/3.4.6/Overview.html
2.Zookeeper開發者編程指南 http://zookeeper.majunwei.com/document/3.4.6/DeveloperProgrammerGuide.html