在ZooKeeper中，所有的讀操作（getData，getChildren和exists）都可以設定監聽。監聽在某些場景下是非常有用的，當你關注某些資料的變化時，如果沒有監聽，你就只能不斷的輪詢檢視資料是否發生了改變，而監聽則可以避免輪詢帶來的開銷。

設定監聽

ZooKeeper的監聽事件僅觸發一次，監聽事件非同步通知客戶端，並支援多種監聽方式。

1. 僅觸發一次
   當資料改變時，一個監聽事件被髮送到客戶端，並取消監聽，除非客戶端再次設定監聽，否則不再監聽。
   如果你呼叫了getData(“/znode1”, true)方法，第二個引數true表示設定監聽，後續如果/znode1發生了改變或刪除，客戶端將收到監聽訊息。而如果/znode1再次發生改變，除非客戶端執行了另一個設定監聽的get操作，否則不會再收到監聽訊息。
   應用使用ZooKeeper的監聽功能的通常方式為：
   1. 客戶端對特定物件設定監聽；
   2. 特定物件發生變化，服務端傳送監聽訊息到客戶端，並取消監聽；
   3. 客戶端收到監聽訊息，發起查詢，並根據需要決定是否再次監聽。
   ZooKeeper保證查詢和監聽是一個原子操作，客戶端查詢資料之後的所有資料變化都能收到監聽。
2. 傳送到客戶端
   要求操作必須成功返回到發起操作的客戶端後，才能傳送通知訊息。監聽被非同步傳送給監聽者。ZooKeeper提供了順序的保證：一個設定了監聽的客戶端在收到監聽事件之前不會看到資料變化。
3. 監聽方式
   這涉及到資料改變的不同方式，ZooKeeper服務端維護了兩個監聽佇列：資料監聽佇列和孩子監聽佇列。getData()和exists()設定資料監聽，getChildren()設定孩子監聽。setData()將觸發資料監聽，create()將觸發一個節點被建立的資料監聽和孩子變化的孩子監聽，delete()同樣將觸發一個數據監聽和孩子監聽。

監聽資訊在ZooKeeper的服務端維護，是一個輕量級操作。當一個客戶端連線到一個新服務端時，監聽將被觸發。在客戶端與服務端斷開連線後，監聽將不能傳送到客戶端，當客戶端重連後，任何先前的註冊監聽將自動重新註冊並根據情況觸發，整個過程自動完成。
存在一種情況將出現監聽事件丟失：當客戶端與服務端斷開連線期間，一個被監聽的節點建立並且被刪除，客戶端將收不到任何監聽事件。
ZooKeeper服務端的監聽列表僅儲存在記憶體中，不做持久化。當一個客戶端與服務端斷開連線後，它所有的watch都會從記憶體中移除，客戶端會在重連後自動重新註冊它的所有watch。

監聽事件

ZooKeeper提供了以下幾種事件型別，下面描述了監聽這些事件的方法：

1. Created event：呼叫exists方法設定監聽；
2. Deleted event：呼叫exists、getData、getChildren設定監聽；
3. Changed event：呼叫getData設定監聽；
4. Child event：呼叫getChildren設定監聽。

取消監聽

客戶端能夠取消監聽，即使連線斷開，客戶端仍然能夠通過設定本地標誌來取消監聽，取消監聽成功後將收到以下事件：
1. Child Remove event：取消getChildren呼叫註冊的監聽成功；
2. Data Remove event：取消exists和getData呼叫註冊的監聽成功。

ZooKeeper對監聽提供的保障

關於監聽，ZooKeeper提供了以下保障：
1. 監聽是有序的，ZooKeeper客戶端庫確保事件、監聽和非同步應答的按序分發；
1. 客戶端在看到一個節點的新資料之前，將先看到該節點的監聽事件；
2. ZooKeeper的監聽事件的順序和ZooKeeper服務檢視到的更新的順序是一致的。

注意事項

使用ZooKeeper的監聽機制，你需要注意：
1. 監聽僅觸發一次；如果你收到了一個監聽事件並且想要繼續監聽，你必須再次設定監聽；
2. 由於監聽是一次性的，並且在你收到監聽訊息和傳送一個新請求（再次監聽）之間存在延遲，因此你不能保證看到節點的每次改變。因此你的應用邏輯不應該依賴監聽節點的每次變化；
3. 對於一個通知訊息一個監聽物件僅會被觸發一次。例如，如果同樣的監聽物件被同時註冊監聽exists和getData，當物件被刪除時，監聽物件將僅被呼叫一次傳送刪除通知；
4. 當客戶端和服務端斷開連線時（例如服務端掛了），你將不會得到任何監聽訊息直到連線重建。由於這個原因，session事件將被髮送給所有監聽事件處理器，通知他們進入安全模式：在斷鏈期間你將不能接收監聽訊息，需要謹慎行事。