《阿里云产品四月刊》—得物 ZooKeeper SLA 也可以 99.99%丨最佳实践（2）

本文来源于阿里云社区电子书《阿里云产品四月刊》

《阿里云产品四月刊》—得物 ZooKeeper SLA 也可以 99.99%丨最佳实践（1）https://developer.aliyun.com/article/1554140

意外发现

通过上面的分析可以得知，需要避免客户端出现对所有 ZNode 进行全面订阅的情况。然而，实际情况是，许多业务代码确实存在这样的逻辑，从 ZTree 的根节点开始遍历所有 ZNode，并对它们进行全面订阅。

或许能够说服一部分业务方进行改进，但无法强制约束所有业务方的使用方式。因此，    解决这个问题的思路在于监控和预防。然而，遗憾的是，ZK   本身并不支持这样的功能， 这就需要对 ZK 源码进行修改。

通过对源码的跟踪和分析，发现问题的根源又指向了 WatchManager，并且仔细研究了这个类的逻辑细节。经过深入理解后，发现这段代码的质量似乎像是由应届毕业生编  写的，存在大量线程和锁的不恰当使用问题。通过查看 Git 记录，发现这个问题可以追溯 到 2007 年 。

然而，令人振奋的是，在这一段时间内，出现了 WatchManagerOptimized（2018）， 通过搜索 ZK 社区的资料，发现了 [ZOOKEEPER-1177]，即在 2011 年，ZK 社区就已经意识到了大量 Watch 导致的内存占用问题，并最终在 2018 年提供了解决方案。正是这个 WatchManagerOptimized 的功劳，看来 ZK 社区早就进行了优化。

有趣的是，ZK 默认情况下并未启用这个类，即使在最新的 3.9.X 版本中，默认仍然使用 WatchManager。也许是因为 ZK 年代久远，渐渐地人们对其关注度降低了。通过询问阿里的同事，确认了 MSE-ZK 也启用了 WatchManagerOptimized，这进一步证实了得物技术团队关注的方向是正确的。

优化探索

锁的优化

在默认版本中，使用的 HashSet 是线程不安全的。在这个版本中，相关操作方法如addWatch 、 removeWatcher 和 triggerWatch 都 是 通 过 在 方 法 上 添 加 了synchronized 重型锁来实现的。而在优化版中，采用了 ConcurrentHashMap 和ReadWriteLock 的组合，以更精细化地使用锁机制。这样一来，在添加 Watch 和触发 Watch 的过程中能够实现更高效的操作。

存储优化

这是关注的重点。从 WatchManager 的分析可以看出， 使用 WatchTables 和Watch2Paths 存储效率并不高。如果 ZNode 的订阅关系较多，将会额外消耗大量无效的内存。

感到惊喜的是，WatchManagerOptimized 在这里使用了“黑科技” -> 位图。利用位图将关系存储进行了大量的压缩，实现了降维优化。

Java BitSet  主要特点：

空间高效：BitSet 使用位数组存储数据，比标准的布尔数组需要更少的空间。

处理快速：进行位操作（如  AND、OR、XOR、翻转）通常比相应的布尔逻辑操作更快。动态扩展：BitSet 的大小可以根据需要动态增长，以容纳更多的位。

BitSet 使用一个 long[] words 来存储数据，long 类型占 8 字节，64 位。数组中每个元素可以存储 64 个数据，数组中数据的存储顺序从左到右，从低位到高位。比如下

图中的 BitSet 的 words 容量为 4，words[0] 从低位到高位分别表示数据 0~63 是否存在，words[1] 的低位到高位分别表示数据 64~127 是否存在，以此类推。其中words[1] = 8，对应的二进制第 8 位为 1，说明此时 BitSet 中存储了一个数据 {67}。

WatchManagerOptimized 使用 BitMap 来存储所有的 Watcher。这样即便是存在1W 的 Watcher 。位图的内存消耗也只有 8Byte*1W/64/1024=1.2KB 。如果换成HashSet ，则至少需要 32Byte*10000/1024=305KB，存储效率相差近 300 倍。

WatchManager.java:private final Map<String, Set<Watcher>> watchTable =
new HashMap<>();private final Map<Watcher, Set<String>> watch2Paths =
new HashMap<>();
WatchManagerOptimized.java:private final ConcurrentHashMap<String,
BitHashSet> pathWatches = new ConcurrentHashMap<String,
BitHashSet>();private final BitMap<Watcher> watcherBitIdMap = new
BitMap<Watcher>();

ZNode 到 Watcher 的映射存储，由 Map 换成了  ConcurrentHashMapBitHashSet>。也就是说不再存储 Set，而是用位图来存储位图索引值。

用 1W 的 ZNode，1W 的 Watcher，极端点走全订阅（所有的 Watcher 订阅所有的 ZNode），做存储效率 PK：

可以看到 11.7MB PK 5.9GB，内存的存储效率相差：516 倍。

逻辑优化

添加监视器： 两个版本都能够在常数时间内完成操作， 但是优化版通过使用ConcurrentHashMap 提供了更好的并发性能。

删除监视器：默认版可能需要遍历整个监视器集合来找到并删除监视器，导致时间复杂  度为 O(n)。而优化版利用 BitSet 和 ConcurrentHashMap，在大多数情况下能够快速定位和删除监视器，O(1)。

触发监视器：默认版的复杂度较高，因为它需要对每个路径上的每个监视器进行操作。  优化版通过更高效的数据结构和减少锁的使用范围，优化了触发监视器的性能。

《阿里云产品四月刊》—得物 ZooKeeper SLA 也可以 99.99%丨最佳实践（3）https://developer.aliyun.com/article/1554138