zookeeper中節點數量理論上僅受限于內存，但一個節點下的子節點數量受限于request/response 1M數據 (size of data / number of znodes)
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
測試客戶端使用zk-smoketest，針對watch的測試則是我自己寫的。基于zk-smoketest我寫了些腳本可以自動跑數據并提取結果，相關腳本可以在這里找到：https://github.com/kevinlynx/zk-benchmark
測試結果
節點數對讀寫性能的影響
測試最大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數對性能有一定影響