一、Zookeeper的一些概念和理解

1、資料模型

如上圖所示，ZooKeeper資料模型的結構與Unix檔案系統很類似，整體上可以看作是一棵樹，每個節點稱做一個ZNode。每個ZNode都可以通過其路徑唯一標識，比如上圖中第三層的第一個ZNode, 它的路徑是/app1/c1。在每個ZNode上可儲存少量資料(預設是1M, 可以通過配置修改, 通常不建議在ZNode上儲存大量的資料)，這個特性非常有用，在後面的典型應用場景中會介紹到。另外，每個ZNode上還儲存了其Acl資訊，這裡需要注意，雖說ZNode的樹形結構跟Unix檔案系統很類似，但是其Acl與Unix檔案系統是完全不同的，每個ZNode的Acl的獨立的，子結點不會繼承父結點的，關於ZooKeeper中的Acl可以參考之前寫過的一篇文章《說說Zookeeper中的ACL》。

2.重要概念 

2.1 ZNode

前文已介紹了ZNode, ZNode根據其本身的特性，可以分為下面兩類：

  ● Regular ZNode: 常規型ZNode, 使用者需要顯式的建立、刪除

  ● Ephemeral ZNode: 臨時型ZNode, 使用者建立它之後，可以顯式的刪除，也可以在建立它的Session結束後，由ZooKeeper Server自動刪除

ZNode還有一個Sequential的特性，如果建立的時候指定的話，該ZNode的名字後面會自動Append一個不斷增加的SequenceNo。

2.2 Session

Client與ZooKeeper之間的通訊，需要建立一個Session，這個Session會有一個超時時間。因為ZooKeeper叢集會把Client的Session資訊持久化，所以在Session沒超時之前，Client與ZooKeeper Server的連線可以在各個ZooKeeper Server之間透明地移動。

在實際的應用中，如果Client與Server之間的通訊足夠頻繁，Session的維護就不需要其它額外的訊息了。否則，ZooKeeper Client會每t/3 ms發一次心跳給Server，如果Client 2t/3 ms沒收到來自Server的心跳回應，就會換到一個新的ZooKeeper Server上。這裡t是使用者配置的Session的超時時間。

2.3 Watcher

ZooKeeper支援一種Watch操作，Client可以在某個ZNode上設定一個Watcher，來Watch該ZNode上的變化。如果該ZNode上有相應的變化，就會觸發這個Watcher，把相應的事件通知給設定Watcher的Client。需要注意的是，ZooKeeper中的Watcher是一次性的，即觸發一次就會被取消，如果想繼續Watch的話，需要客戶端重新設定Watcher。這個跟epoll裡的oneshot模式有點類似。

3. ZooKeeper特性 

3.1 讀、寫(更新)模式

在ZooKeeper叢集中，讀可以從任意一個ZooKeeper Server讀，這一點是保證ZooKeeper比較好的讀效能的關鍵；寫的請求會先Forwarder到Leader，然後由Leader來通過ZooKeeper中的原子廣播協議，將請求廣播給所有的Follower，Leader收到一半以上的寫成功的Ack後，就認為該寫成功了，就會將該寫進行持久化，並告訴客戶端寫成功了。

3.2 WAL和Snapshot

和大多數分散式系統一樣，ZooKeeper也有WAL(Write-Ahead-Log)，對於每一個更新操作，ZooKeeper都會先寫WAL, 然後再對記憶體中的資料做更新，然後向Client通知更新結果。另外，ZooKeeper還會定期將記憶體中的目錄樹進行Snapshot，落地到磁碟上，這個跟HDFS中的FSImage是比較類似的。這麼做的主要目的，一當然是資料的持久化，二是加快重啟之後的恢復速度，如果全部通過Replay WAL的形式恢復的話，會比較慢。

3.3 FIFO

對於每一個ZooKeeper客戶端而言，所有的操作都是遵循FIFO順序的，這一特性是由下面兩個基本特性來保證的：一是ZooKeeper Client與Server之間的網路通訊是基於TCP，TCP保證了Client/Server之間傳輸包的順序；二是ZooKeeper Server執行客戶端請求也是嚴格按照FIFO順序的。

3.4 Linearizability

在ZooKeeper中，所有的更新操作都有嚴格的偏序關係，更新操作都是序列執行的，這一點是保證ZooKeeper功能正確性的關鍵。

4. ZooKeeper Client API

ZooKeeper Client Library提供了豐富直觀的API供使用者程式使用，下面是一些常用的API：

  ● create(path, data, flags): 建立一個ZNode, path是其路徑，data是要儲存在該ZNode上的資料，flags常用的有: PERSISTEN, PERSISTENT_SEQUENTAIL, EPHEMERAL, EPHEMERAL_SEQUENTAIL

  ● delete(path, version): 刪除一個ZNode，可以通過version刪除指定的版本, 如果version是-1的話，表示刪除所有的版本

  ● exists(path, watch): 判斷指定ZNode是否存在，並設定是否Watch這個ZNode。這裡如果要設定Watcher的話，Watcher是在建立ZooKeeper例項時指定的，如果要設定特定的Watcher的話，可以呼叫另一個過載版本的exists(path, watcher)。以下幾個帶watch引數的API也都類似

  ● getData(path, watch): 讀取指定ZNode上的資料，並設定是否watch這個ZNode

  ● setData(path, watch): 更新指定ZNode的資料，並設定是否Watch這個ZNode

  ● getChildren(path, watch): 獲取指定ZNode的所有子ZNode的名字，並設定是否Watch這個ZNode

  ● sync(path): 把所有在sync之前的更新操作都進行同步，達到每個請求都在半數以上的ZooKeeper Server上生效。path引數目前沒有用

  ● setAcl(path, acl): 設定指定ZNode的Acl資訊

  ● getAcl(path): 獲取指定ZNode的Acl資訊

ZooKeeper 節點型別

ZooKeeper 節點是有生命週期的，這取決於節點的型別。在 ZooKeeper 中，節點型別可以分為持久節點（PERSISTENT ）、臨時節點（EPHEMERAL），以及時序節點（SEQUENTIAL ），具體在節點建立過程中，一般是組合使用，可以生成以下 4 種節點型別。

持久節點（PERSISTENT）

所謂持久節點，是指在節點建立後，就一直存在，直到有刪除操作來主動清除這個節點——不會因為建立該節點的客戶端會話失效而消失。

持久順序節點（PERSISTENT_SEQUENTIAL）

這類節點的基本特性和上面的節點型別是一致的。額外的特性是，在ZK中，每個父節點會為他的第一級子節點維護一份時序，會記錄每個子節點建立的先後順序。基於這個特性，在建立子節點的時候，可以設定這個屬性，那麼在建立節點過程中，ZK會自動為給定節點名加上一個數字字尾，作為新的節點名。這個數字字尾的範圍是整型的最大值。

臨時節點（EPHEMERAL）

和持久節點不同的是，臨時節點的生命週期和客戶端會話繫結。也就是說，如果客戶端會話失效，那麼這個節點就會自動被清除掉。注意，這裡提到的是會話失效，而非連線斷開。另外，在臨時節點下面不能建立子節點。

臨時順序節點（EPHEMERAL_SEQUENTIAL）

關於Zookeeper和客戶端的通訊

在實際的應用中，如果Client與Server之間的通訊足夠頻繁，Session的維護就不需要其它額外的訊息了。否則，ZooKeeper Client會每t/3 ms發一次心跳給Server，如果Client 2t/3 ms沒收到來自Server的心跳回應，就會換到一個新的ZooKeeper Server上。這裡t是使用者配置的Session的超時時間。

官方文件地址：

二、ZooKeeper服務端命令使用

1、使用命令列客戶端

./zkCli.sh -server 127.0.0.1:2180

2、啟動和關閉

./zkServer.sh start

./zkServer.sh stop

3、檢視叢集狀態

zkServer.sh status

三、Zookeeper叢集

步驟：

1、conf/zoo_sample.cfg檔案複製一份，並更名為zoo.cfg

2、配置zoo.cfg

3、根據配置的dataDir和dataLogDir變數建立相應的目錄

4、在dataDir目錄下建立一個myid檔案，寫入按照zoo.cfg檔案的server.A中A的數值，比如

server.1=172.16.1.164:2888:3888

server.2=172.16.1.165:2888:3888

server.3=172.16.1.166:2888:3888

那麼在myid檔案中寫入1，或者2或者3。

叢集配置例項如下，供參考：

具體參見官方文件：

四、Zookeeper學習資料