zookeeper的watch機制用於資料變更時zookeeper的主動通知。watch可以被附加到每一個節點上，那麼如果一個應用有10W個節點，那zookeeper中就可能有10W個watch（甚至更多）。每一次在zookeeper完成改寫節點的操作時就會檢測是否有對應的watch，有的話則會通知到watch。Zookeeper-Watcher機制與非同步呼叫原理

本文將關注以下內容：

• zookeeper的效能是否會受節點數量的影響
• zookeeper的效能是否會受watch數量的影響

測試方法

在3臺機器上分別部署一個zookeeper，版本為3.4.3，機器配置：

Intel(R) Xeon(R) CPU E5-2430 0 @ 2.20GHz

16G

java version "1.6.0_32"
Java(TM) SE Runtime Environment (build 1.6.0_32-b05)
OpenJDK (Taobao) 64-Bit Server VM (build 20.0-b12-internal, mixed mode)
 

大部分實驗JVM堆大小使用預設，也就是1/4 RAM：

java -XX:+PrintFlagsFinal -version | grep HeapSize

測試結果

節點數對讀寫效能的影響

測試最大10W個節點，度量1秒內運算元(ops)：

可見節點數的增加並不會對zookeeper讀寫效能造成影響。

節點資料大小對讀寫效能的影響

這個網上其實已經有公認的結論。本身單個節點資料越大，對網路方面的吞吐就會造成影響，所以其資料越大讀寫效能越低也在預料之中。

寫資料會在zookeeper叢集內進行同步，所以其速度整體會比讀資料更慢。該實驗需要把超時時間進行一定上調，同時我也把JVM最大堆大小調整到8G。

測試結果很明顯，節點資料大小會嚴重影響zookeeper效率。

watch對讀寫效能的影響

zk-smoketest自帶的latency測試有個引數--watch_multiple用來指定watch的數量，但其實僅是指定客戶端的數量，在server端通過echo whcp | nc 127.0.0.1 4181會發現實際每個節點還是隻有一個watch。

在我寫的測試中，則是通過建立多個客戶端來模擬單個節點上的多個watch。這也更符合實際應用。同時對節點的寫也是在另一個獨立的客戶端中，這樣可以避免zookeeper client的實現對測試帶來的干擾。

每一次完整的測試，首先是對每個節點新增節點資料的watch，然後在另一個客戶端中對這些節點進行資料改寫，收集這些改寫操作的耗時，以確定新增的watch對這些寫操作帶來了多大的影響。

圖中，0 watch表示沒有對節點新增watch；1 watch表示有一個客戶端對每個節點進行了watch；3 watch表示有其他3個客戶端對每個節點進行了watch；依次類推。

可見，watch對寫操作還是有較大影響的，畢竟需要進行網路傳輸。同樣，這裡也顯示出整個zookeeper的watch數量同節點數量一樣對整體效能沒有影響。

總體結論

• 對單個節點的操作並不會因為zookeeper中節點的總數而受到影響
• 資料大小對zookeeper的效能有較大影響，效能和記憶體都會
• 單個節點上獨立session的watch數對效能有一定影響