一個真正的寫數據流程是怎么樣的？一個真正的讀數據流程是怎么樣的？一個真正的同步數據流程是怎么樣的？從哪里到哪里？什么時候開始進行同步？同步點是什么？同步的數據有哪些？ZXID最大意味著什么？

1.ZooKeeper是什么？

ZooKeeper是一個分布式的，開放源碼的分布式應用程序協調服務，是Google的Chubby一個開源的實現，它是集群的管理者，監視著集群中各個節點的狀態根據節點提交的反饋進行下一步合理操作。最終，將簡單易用的接口和性能高效、功能穩定的系統提供給用戶

2.ZooKeeper提供了什么？1)文件系統（持久化節點? 和? 臨時節點的使用可以方便進行服務注冊和服務發現等集群管理? 以及順序編號可以方便實現分布式鎖（保持時序的）和分布式隊列（先進先出）以及命名服務） 2)通知機制（監聽機制可以實現 數據的發布與訂閱 負載均衡 以及配置管理）

3.Zookeeper文件系統：每個子目錄項如 NameService 都被稱作為znode，和文件系統一樣，我們能夠自由的增加、刪除znode，在一個znode下增加、刪除子znode，唯一的不同在于znode是可以存儲數據的。

有四種類型的znode：（臨時節點可以用來服務發現 服務注冊?? 順序編號可以用來實現保持時序的分布式鎖 命名服務（分布式自增id）分布式隊列先進先出 ）

1、PERSISTENT-持久化目錄節點：客戶端與zookeeper斷開連接后，該節點依舊存在

2、PERSISTENT_SEQUENTIAL-持久化順序編號目錄節點：客戶端與zookeeper斷開連接后，該節點依舊存在，只是Zookeeper給該節點名稱進行順序編號

3、EPHEMERAL-臨時目錄節點：客戶端與zookeeper斷開連接后，該節點被刪除（node_0000000001）

4、EPHEMERAL_SEQUENTIAL-臨時順序編號目錄節點：客戶端與zookeeper斷開連接后，該節點被刪除，只是Zookeeper給該節點名稱進行順序編號

4.Zookeeper通知機制：客戶端注冊監聽它關心的目錄節點，當目錄節點發生變化（數據改變、被刪除、子目錄節點增加刪除 實現對應接口時，調用對應的函數實現--回調）時，zookeeper會通知客戶端。（zklient訂閱 指定路徑的監聽接口）

5.Zookeeper做了什么？：1.命名服務? ?2.配置管理? ?3.集群管理（服務發現和master選舉） ? 4.分布式鎖 （獨占鎖和保持時序） 5.隊列管理 6 負載均衡

6.Zookeeper命名服務：在zookeeper的文件系統里創建一個目錄，即有唯一的path。在我們使用tborg無法確定上游程序的部署機器時即可與下游程序約定好path，通過path即能互相探索發現。（臨時節點順序編號）

7.Zookeeper的配置管理：程序總是需要配置的，如果程序分散部署在多臺機器上，要逐個改變配置就變得困難。現在把這些配置全部放到zookeeper上去，保存在 Zookeeper 的某個目錄節點中，然后所有相關應用程序對這個目錄節點進行監聽，一旦配置信息發生變化，每個應用程序就會收到 Zookeeper 的通知，然后從 Zookeeper 獲取新的配置信息應用到系統中就好。（監聽機制 -- 回調實現）

8.Zookeeper集群管理：所謂集群管理無在乎兩點：是否有機器退出和加入（服務發現）、選舉master。

對于第一點，所有機器約定在父目錄GroupMembers下創建臨時目錄節點，然后監聽父目錄節點的子節點變化消息。一旦有機器掛掉，該機器與 zookeeper的連接斷開，其所創建的臨時目錄節點被刪除，所有其他機器都收到通知：某個兄弟目錄被刪除，于是，所有人都知道：它上船了。（臨時節點和監聽機制）

新機器加入也是類似，所有機器收到通知：新兄弟目錄加入，highcount又有了，對于第二點，我們稍微改變一下，所有機器創建臨時順序編號目錄節點，每次選取編號最小的機器作為master就好。

9.Zookeeper分布式鎖

有了zookeeper的一致性文件系統，鎖的問題變得容易。鎖服務可以分為兩類，一個是保持獨占（監聽機制），另一個是控制時序（順序編號和監聽機制）。

對于第一類，我們將zookeeper上的一個znode看作是一把鎖，通過createznode的方式來實現。所有客戶端都去創建 /distribute_lock 節點，最終成功創建的那個客戶端也即擁有了這把鎖。用完刪除掉自己創建的distribute_lock 節點就釋放出鎖。

對于第二類， /distribute_lock 已經預先存在，所有客戶端在它下面創建臨時順序編號目錄節點，和選master一樣，編號最小的獲得鎖，用完刪除，依次方便。

10.Zookeeper隊列管理

兩種類型的隊列：

1、同步隊列，當一個隊列的成員都聚齊時，這個隊列才可用，否則一直等待所有成員到達。

2、隊列按照 FIFO 方式進行入隊和出隊操作。

第一類，在約定目錄下創建臨時目錄節點，監聽節點數目是否是我們要求的數目。

第二類，和分布式鎖服務中的控制時序場景基本原理一致，入列有編號，出列按編號。

11.分布式與數據復制

Zookeeper作為一個集群提供一致的數據服務，自然，它要在所有機器間做數據復制。數據復制的好處：

1、容錯：一個節點出錯，不致于讓整個系統停止工作，別的節點可以接管它的工作；

2、提高系統的擴展能力 ：把負載分布到多個節點上，或者增加節點來提高系統的負載能力；

3、提高性能：讓客戶端本地訪問就近的節點，提高用戶訪問速度。

從客戶端讀寫訪問的透明度來看，數據復制集群系統分下面兩種：

1、寫主(WriteMaster) ：對數據的修改提交給指定的節點。讀無此限制，可以讀取任何一個節點。這種情況下客戶端需要對讀與寫進行區別，俗稱讀寫分離；

2、寫任意(Write Any)：對數據的修改可提交給任意的節點，跟讀一樣。這種情況下，客戶端對集群節點的角色與變化透明。

對zookeeper來說，它采用的方式是寫任意。通過增加機器，它的讀吞吐能力和響應能力擴展性非常好，而寫，隨著機器的增多吞吐能力肯定下降（這也是它建立observer的原因），而響應能力則取決于具體實現方式，是延遲復制保持最終一致性，還是立即復制快速響應。

12.Zookeeper角色描述

領導者（Leader）：領導者負責進行投票的發起和決議，更新系統狀態。

學習者（Learner）：

跟隨者（Follower）：follower用于接收客戶請求并向客戶端返回結果，在選主過程中參與投票。

觀察者（observer）：observer可以接收客戶端連接，將寫請求轉發給leader節點。但observer不參加投票過程，只同步leader的狀態。observer的目的是為了擴展系統，提高讀取速度。

客戶端（client）：請求發起方

13.Zookeeper與客戶端

14.Zookeeper設計目的

1.最終一致性：client不論連接到哪個Server，展示給它都是同一個視圖，這是zookeeper最重要的性能。

2.可靠性：具有簡單、健壯、良好的性能，如果消息被到一臺服務器接受，那么它將被所有的服務器接受。

3.實時性：Zookeeper保證客戶端將在一個時間間隔范圍內獲得服務器的更新信息，或者服務器失效的信息。但由于網絡延時等原因，Zookeeper不能保證兩個客戶端能同時得到剛更新的數據，如果需要最新數據，應該在讀數據之前調用sync()接口。

4.等待無關（wait-free）：慢的或者失效的client不得干預快速的client的請求，使得每個client都能有效的等待。

5.原子性：更新只能成功或者失敗，沒有中間狀態。

6.順序性：包括全局有序和偏序兩種：全局有序是指如果在一臺服務器上消息a在消息b前發布，則在所有Server上消息a都將在消息b前被發布；偏序是指如果一個消息b在消息a后被同一個發送者發布，a必將排在b前面。

15.Zookeeper工作原理

Zookeeper 的核心是原子廣播，這個機制保證了各個Server之間的同步。實現這個機制的協議叫做Zab協議。Zab協議有兩種模式，它們分別是恢復模式（選主）和廣播模式（同步）。當服務啟動或者在領導者崩潰后，Zab就進入了恢復模式，當領導者被選舉出來，且大多數Server完成了和 leader的狀態同步以后，恢復模式就結束了。狀態同步保證了leader和Server具有相同的系統狀態。

為了保證事務的順序一致性，zookeeper采用了遞增的事務id號（zxid）來標識事務。所有的提議（proposal）都在被提出的時候加上了zxid。實現中zxid是一個64位的數字，它高32位是epoch用來標識leader關系是否改變，每次一個leader被選出來，它都會有一個新的epoch，標識當前屬于那個leader的統治時期。低32位用于遞增計數。

16.Zookeeper 下 Server工作狀態

每個Server在工作過程中有三種狀態：LOOKING：當前Server不知道leader是誰，正在搜尋；LEADING：當前Server即為選舉出來的leader；FOLLOWING：leader已經選舉出來，當前Server與之同步

17.Zookeeper選主流程(basic paxos)（沒明白！！！）

當leader崩潰或者leader失去大多數的follower，這時候zk進入恢復模式，恢復模式需要重新選舉出一個新的leader，讓所有的Server都恢復到一個正確的狀態。Zk的選舉算法有兩種：一種是基于basic paxos實現的，另外一種是基于fast paxos算法實現的。系統默認的選舉算法為fast paxos。

1.選舉線程由當前Server發起選舉的線程擔任，其主要功能是對投票結果進行統計，并選出推薦的Server；

2.選舉線程首先向所有Server發起一次詢問(包括自己)；

3.選舉線程收到回復后，驗證是否是自己發起的詢問(驗證zxid是否一致)，然后獲取對方的id(myid)，并存儲到當前詢問對象列表中，最后獲取對方提議的leader相關信息(id,zxid)，并將這些信息存儲到當次選舉的投票記錄表中；

4.收到所有Server回復以后，就計算出zxid最大的那個Server（?? zxid最大意味著什么？），并將這個Server相關信息設置成下一次要投票的Server；

5.線程將當前zxid最大的Server設置為當前Server要推薦的Leader，如果此時獲勝的Server獲得n/2 + 1的Server票數，設置當前推薦的leader為獲勝的Server，將根據獲勝的Server相關信息設置自己的狀態，否則，繼續這個過程，直到leader被選舉出來。 通過流程分析我們可以得出：要使Leader獲得多數Server的支持，則Server總數必須是奇數2n+1，且存活的Server的數目不得少于n+1. 每個Server啟動后都會重復以上流程。在恢復模式下，如果是剛從崩潰狀態恢復的或者剛啟動的server還會從磁盤快照中恢復數據和會話信息，zk會記錄事務日志并定期進行快照，方便在恢復時進行狀態恢復。選主的具體流程圖所示：

18.Zookeeper選主流程（fast paxos）（沒明白！！！）

fast paxos流程是在選舉過程中，某Server首先向所有Server提議自己要成為leader，當其它Server收到提議以后，解決epoch和 zxid的沖突，并接受對方的提議，然后向對方發送接受提議完成的消息，重復這個流程，最后一定能選舉出Leader。

19.Zookeeper同步流程（沒明白？）

數據同步是指：每臺Cilent機器都連接一個Follower或leader。當Cilent上數據被修改后，其連接的Follower或leader上的Server會首先接收到，而leader會隨時檢測所有與的Follower上的Server如果有數據變化就將數據同步到其他Follower上，

hadoop2.0中使用zookeeper確保整個NameService中只有一個活躍的NameNode（會有多個代用的NameNode但處于代用狀態），當一個nameNode 當掉或會啟用其他的備用的NameNode。此外在Hbase集群中也會使用zookeeper來保證Hbase集群中只有一個HMaster，同時通過zookeeper將Hbase客戶端、RegionServer、Master三者聯系在一起。

選完Leader以后，zk就進入狀態同步過程。

1. Leader等待server連接；

2 .Follower連接leader，將最大的zxid發送給leader；（最大的zxid意味著什么？）

3 .Leader根據follower的zxid確定同步點；（同步點意味著什么？）

4 .完成同步后通知follower 已經成為uptodate狀態；（到底是誰完成同步？）

5 .Follower收到uptodate消息后，又可以重新接受client的請求進行服務了。

20.Zookeeper工作流程-Leader --

1 .恢復數據；（恢復什么數據？怎么恢復？）

2 .維持與Learner的心跳（ping消息），接收Learner請求（寫請求和同步請求? ）并判斷Learner的請求消息類型；

3 .Learner的消息類型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，根據不同的消息類型，進行不同的處理。

PING 消息是指Learner的心跳信息；

REQUEST消息是Follower發送的提議信息，包括寫請求及同步請求；

ACK消息是 Follower的對提議的回復，超過半數的Follower通過，則commit該提議；

REVALIDATE消息是用來延長SESSION有效時間。

21.Zookeeper工作流程-Follower

Follower主要有四個功能：

1.向Leader發送請求（PING消息、REQUEST消息、ACK消息、REVALIDATE消息）；

2.接收Leader消息并進行處理；

3.接收Client的請求，如果為寫請求，發送給Leader進行投票；（為什么要進行投票？）

4.返回Client結果。

Follower的消息循環處理如下幾種來自Leader的消息：

1 .PING消息： 心跳消息；

2 .PROPOSAL消息：Leader發起的提案，要求Follower投票；

3 .COMMIT消息：服務器端最新一次提案的信息；

4 .UPTODATE消息：表明同步完成；

5 .REVALIDATE消息：根據Leader的REVALIDATE結果，關閉待revalidate的session還是允許其接受消息；

6 .SYNC消息：返回SYNC結果到客戶端，這個消息最初由客戶端發起，用來強制得到最新的更新。

2、Zookeeper 的讀寫機制

Zookeeper是一個由多個server組成的集群；一個leader，多個follower；每個server保存一份數據副本；全局數據一致；分布式讀寫；更新請求轉發，由leader實施

3、Zookeeper 的保證

?更新請求順序進行，來自同一個client的更新請求按其發送順序依次執行（ZXID保證）；數據更新原子性，一次數據更新要么成功，要么失敗；全局唯一數據視圖，client無論連接到哪個server，數據視圖都是一致的（全局一致性）；實時性，在一定事件范圍內，client能讀到最新數據

4、Zookeeper節點寫數據操作流程

注：1.在Client向Follwer發出一個寫的請求 -> 2.Follwer把請求發送給Leader -> 3.Leader接收到以后開始發起投票并通知Follwer進行投票 -> 4.Follwer把投票結果發送給Leader -> 5.Leader將結果匯總后如果需要寫入，則開始寫入同時把寫入操作通知給Leader，然后commit; -> 6.Follwer把請求結果返回給Client

5、Zookeeper leader 選舉

? 半數通過

– 3臺機器 掛一臺 2>3/2

– 4臺機器 掛2臺 2！>4/2

? A提案說，我要選自己，B你同意嗎？C你同意嗎？B說，我同意選A；C說，我同意選A。(注意，這里超過半數了，其實在現實世界選舉已經成功了。

但是計算機世界是很嚴格，另外要理解算法，要繼續模擬下去。)

? 接著B提案說，我要選自己，A你同意嗎；A說，我已經超半數同意當選，你的提案無效；C說，A已經超半數同意當選，B提案無效。

? 接著C提案說，我要選自己，A你同意嗎；A說，我已經超半數同意當選，你的提案無效；B說，A已經超半數同意當選，C的提案無效。

? 選舉已經產生了Leader，后面的都是follower，只能服從Leader的命令。而且這里還有個小細節，就是其實誰先啟動誰當頭。

6、zxid

? znode節點的狀態信息中包含czxid, 那么什么是zxid呢?

? ZooKeeper狀態的每一次改變, 都對應著一個遞增的Transaction id, 該id稱為zxid. 由于zxid的遞增性質, 如果zxid1小于zxid2, 那么zxid1肯定先于zxid2發生.

創建任意節點, 或者更新任意節點的數據, 或者刪除任意節點, 都會導致Zookeeper狀態發生改變, 從而導致zxid的值增加.

7、Zookeeper工作原理

? Zookeeper的核心是原子廣播，這個機制保證了各個server之間的同步。實現這個機制的協議叫做Zab協議。Zab協議有兩種模式，它們分別是恢復模式和廣播模式。當服務啟動或者在領導者崩潰后，Zab就進入了恢復模式，當領導者被選舉出來，且大多數server的完成了和leader的狀態同步以后，恢復模式就結束了。狀態同步保證了leader和server具有相同的系統狀態(什么狀態？)

? 一旦leader已經和多數的follower進行了狀態同步后，他就可以開始廣播消息了，即進入廣播狀態。這時候當一個server加入zookeeper服務中，它會在恢復模式下啟動，發現leader，并和leader進行狀態同步。待到同步結束，它也參與消息廣播。Zookeeper服務一直維持在Broadcast狀態，直到leader崩潰了或者leader失去了大部分的followers支持。

? 廣播模式需要保證proposal被按順序處理，因此zk采用了遞增的事務id號(zxid)來保證。所有的提議(proposal)都在被提出的時候加上了zxid。實現中zxid是一個64為的數字，它高32位是epoch用來標識leader關系是否改變，每次一個leader被選出來，它都會有一個新的epoch。低32位是個遞增計數。

? 當leader崩潰或者leader失去大多數的follower，這時候zk進入恢復模式，恢復模式需要重新選舉出一個新的leader，讓所有的server都恢復到一個正確的狀態。

? 每個Server啟動以后都詢問其它的Server它要投票給誰。對于其他server的詢問，server每次根據自己的狀態都回復自己推薦的leader的id和上一次處理事務的zxid（系統啟動時每個server都會推薦自己）收到所有Server回復以后，就計算出zxid最大的哪個Server，并將這個Server相關信息設置成下一次要投票的Server。計算這過程中獲得票數最多的的sever為獲勝者，如果獲勝者的票數超過半數，則改server被選為leader。否則，繼續這個過程，直到leader被選舉出來。

? leader就會開始等待其他server連接；Follower連接leader，將最大的zxid發送給leader；Leader根據follower的zxid確定同步點（同步點在哪?）；完成同步后通知follower 已經成為uptodate狀態；Follower收到uptodate消息后，又可以重新接受client的請求進行服務了

8、數據一致性與paxos 算法

? 據說Paxos算法的難理解與算法的知名度一樣令人敬仰，所以我們先看如何保持數據的一致性，這里有個原則就是：

? 在一個分布式數據庫系統中，如果各節點的初始狀態一致，每個節點都執行相同的操作序列，那么他們最后能得到一個一致的狀態。

? Paxos算法解決的什么問題呢，解決的就是保證每個節點執行相同的操作序列。好吧，這還不簡單，master維護一個全局寫隊列，所有寫操作都必須 放入這個隊列編號，那么無論我們寫多少個節點，只要寫操作是按編號來的，就能保證一致性。沒錯，就是這樣，可是如果master掛了呢。

? Paxos算法通過投票來對寫操作進行全局編號，同一時刻，只有一個寫操作被批準，同時并發的寫操作要去爭取選票，只有獲得過半數選票的寫操作才會被 批準（所以永遠只會有一個寫操作得到批準），其他的寫操作競爭失敗只好再發起一輪投票，就這樣，在日復一日年復一年的投票中，所有寫操作都被嚴格編號排 序。編號嚴格遞增，當一個節點接受了一個編號為100的寫操作，之后又接受到編號為99的寫操作（因為網絡延遲等很多不可預見原因），它馬上能意識到自己 數據不一致了，自動停止對外服務并重啟同步過程。任何一個節點掛掉都不會影響整個集群的數據一致性（總2n+1臺，除非掛掉大于n臺）。

總結:? Zookeeper 作為 Hadoop 項目中的一個子項目，是 Hadoop 集群管理的一個必不可少的模塊，它主要用來控制集群中的數據，如它管理 Hadoop 集群中的 NameNode，還有 Hbase 中 Master Election、Server 之間狀態同步等。\

9、Observer

?Zookeeper需保證高可用和強一致性； 為了支持更多的客戶端，需要增加更多Server； Server增多，投票階段延遲增大，影響性能； 權衡伸縮性和高吞吐率，引入Observer; Observer不參與投票； Observers接受客戶端的連接，并將寫請求轉發給leader節點； 加入更多Observer節點，提高伸縮性，同時不影響吞吐率

10、?為什么zookeeper集群的數目，一般為奇數個？

?Leader選舉算法采用了Paxos協議；

?Paxos核心思想：當多數Server寫成功，則任務數據寫成功如果有3個Server，則兩個寫成功即可；如果有4或5個Server，則三個寫成功即可。?Server數目一般為奇數（3、5、7）如果有3個Server，則最多允許1個Server掛掉；如果有4個Server，則同樣最多允許1個Server掛掉由此，我們看出3臺服務器和4臺服務器的的容災能力是一樣的，所以為了節省服務器資源，一般我們采用奇數個數，作為服務器部署個數。

11、Zookeeper 的數據模型

? 層次化的目錄結構，命名符合常規文件系統規范 ? 每個節點在zookeeper中叫做znode,并且其有一個唯一的路徑標識 ? 節點Znode可以包含數據和子節點，但是EPHEMERAL類型的節點不能有子節點 ? Znode中的數據可以有多個版本，比如某一個路徑下存有多個數據版本，那么查詢這個路徑下的數據就需要帶上版本 ? 客戶端應用可以在節點上設置監視器 ? 節點不支持部分讀寫，而是一次性完整讀寫

12、Zookeeper 的節點

? Znode有兩種類型，短暫的（ephemeral）和持久的（persistent）

? Znode的類型在創建時確定并且之后不能再修改

? 短暫znode的客戶端會話結束時，zookeeper會將該短暫znode刪除，短暫znode不可以有子節點

? 持久znode不依賴于客戶端會話，只有當客戶端明確要刪除該持久znode時才會被刪除

? Znode有四種形式的目錄節點

? PERSISTENT（持久的）

? EPHEMERAL(暫時的)

? PERSISTENT_SEQUENTIAL（持久化順序編號目錄節點）

? EPHEMERAL_SEQUENTIAL（暫時化順序編號目錄節點）

Zookeeper 監視（Watches） 簡介

Zookeeper C API 的聲明和描述在 include/zookeeper.h 中可以找到，另外大部分的 Zookeeper C API 常量、結構體聲明也在 zookeeper.h 中，如果如果你在使用 C API 是遇到不明白的地方，最好看看 zookeeper.h，或者自己使用 doxygen 生成 Zookeeper C API 的幫助文檔。

Zookeeper 中最有特色且最不容易理解的是監視(Watches)。Zookeeper 所有的讀操作——getData(),getChildren(), 和exists()都 可以設置監視(watch)，監視事件可以理解為一次性的觸發器， 官方定義如下： a watch event is one-time trigger, sent to the client that set the watch, which occurs when the data for which the watch was set changes。對此需要作出如下理解：

（一次性觸發）One-time trigger

當設置監視的數據發生改變時，該監視事件會被發送到客戶端，例如，如果客戶端調用了 getData("/znode1", true) 并且稍后 /znode1 節點上的數據發生了改變或者被刪除了，客戶端將會獲取到/znode1 發生變化的監視事件，而如果 /znode1 再一次發生了變化，除非客戶端再次對 /znode1設置監視，否則客戶端不會收到事件通知。

（發送至客戶端）Sent to the client

Zookeeper 客戶端和服務端是通過 socket 進行通信的，由于網絡存在故障，所以監視事件很有可能不會成功地到達客戶端，監視事件是異步發送至監視者的，Zookeeper 本身提供了保序性(ordering guarantee)：即客戶端只有首先看到了監視事件后，才會感知到它所設置監視的 znode 發生了變化(a client will never see a change for which it has set a watch until it first sees the watch event). 網絡延遲或者其他因素可能導致不同的客戶端在不同的時刻感知某一監視事件，但是不同的客戶端所看到的一切具有一致的順序。

（被設置 watch 的數據）The data for which the watch was set

這意味著znode 節點本身具有不同的改變方式。你也可以想象 Zookeeper 維護了兩條監視鏈表：數據監視和子節點監視(data watches and child watches) getData() and exists() 設置數據監視，getChildren() 設置子節點監視。或者，你也可以想象 Zookeeper 設置的不同監視返回不同的數據，getData() 和 exists() 返回 znode節點的相關信息，而 getChildren() 返回子節點列表。因此， setData()會觸發設置在某一節點上所設置的數據監視(假定數據設置成功)，而一次成功的 create()操作則會出發當前節點上所設置的數據監視以及父節點的子節點監視。一次成功的 delete()操作將會觸發當前節點的數據監視和子節點監視事件，同時也會觸發該節點父節點的child watch。

Zookeeper中的監視是輕量級的，因此容易設置、維護和分發。當客戶端與 Zookeeper服務器端失去聯系時，客戶端并不會收到監視事件的通知，只有當客戶端重新連接后，若在必要的情況下，以前注冊的監視會重新被注冊并觸發，對于開發人員來說這通常是透明的。只有一種情況會導致監視事件的丟失，即：通過 exists() 設置了某個 znode 節點的監視，但是如果某個客戶端在此znode 節點被創建和刪除的時間間隔內與 zookeeper 服務器失去了聯系，該客戶端即使稍后重新連接zookeeper服務器后也得不到事件通知。

Watch事件類型：

ZOO_CREATED_EVENT：節點創建事件，需要watch一個不存在的節點，當節點被創建時觸發，此watch通過zoo_exists()設置

ZOO_DELETED_EVENT：節點刪除事件，此watch通過zoo_exists()或zoo_get()設置

ZOO_CHANGED_EVENT：節點數據改變事件，此watch通過zoo_exists()或zoo_get()設置

ZOO_CHILD_EVENT：子節點列表改變事件，此watch通過zoo_get_children()或zoo_get_children2()設置

ZOO_SESSION_EVENT：會話失效事件，客戶端與服務端斷開或重連時觸發

ZOO_NOTWATCHING_EVENT：watch移除事件，服務端出于某些原因不再為客戶端watch節點時觸發