得物 ZooKeeper SLA 也可以 99.99%
1. 背景ZooKeeper（ZK）是一个诞生于 2007 年的分布式应用程序协调服务。尽管出于一些特别的历史缘故原由，很多业务场景仍然不得不依赖它。比如，Kafka、任务调度等。特别是在 Flink 混合部署 ETCD 解耦 时，业务方曾要求绝对的稳固性，并猛烈发起不要利用自建的 ZooKeeper。出于对稳固性的考量，采用了阿里的 MSE-ZK。自从 2022 年 9 月份开始利用至今，得物技术团队没有遇到任何稳固性问题，SLA 的可靠性确实达到了 99.99%。
在 2023 年，部分业务利用了自建的 ZooKeeper（ZK）集群，然后利用过程中 ZK 出现了几次波动，随后得物 SRE 开始接管部分自建集群，并进行了几轮稳固性加固的尝试。接管过程中得物发现 ZooKeeper 在运行一段时间后，内存占用率会不断增加，容易导致内存耗尽（OOM）的问题。得物技术团队对这一征象非常好奇，因此也参与了办理这个问题的探索过程。
2. 探索分析
2.1 确定方向
在排查问题时，非常荣幸地发现了一个测试环境的故障现场，该集群中的两个节点恰恰处于 OOM 的边缘状态。
https://pic4.zhimg.com/v2-60ec8d799aca9912c7ec040c16c9160f_b.jpg有了故障现场，那么一般情况下距离乐成终点只剩下 50%。内存偏高，按以往的经验来看，要么是非堆，要么是堆内有问题。从火焰图和 jstat 都能证实：是堆内的问题。
https://pic4.zhimg.com/v2-3f98ab3a623c2fa1611cf8746a6f9e9b_b.jpghttps://pic3.zhimg.com/v2-097738dd21e9923ab0d5c37e36e01fd2_b.jpg如图所示：说明 JVM 堆内存在某种资源占用了大量的内存，而且 FGC 都无法开释。
2.2 内存分析
为了探究 JVM 堆中内存占用分布，得物技术团队立刻做了一个 JVM 堆 Dump。分析发现 JVM 内存被 childWatches 和 dataWatches 大量占用。
https://pic1.zhimg.com/v2-48d6ee33eb37fe14cc0a45b9bcf1edf0_b.jpghttps://pic2.zhimg.com/v2-834dff17f71176aa8069525c09dbcbbd_b.jpgdataWatches：跟踪 znode 节点数据的变化。
childWatches：跟踪 znode 节点结构 (tree) 的变化。childWatches 和 dataWatches 同源于 WatcherManager。
颠末资料排查，发现 WatcherManager 主要负责管理 Watcher。ZooKeeper（ZK）客户端首先将 Watcher 注册到 ZooKeeper 服务器上，然后由 ZooKeeper 服务器利用 WatcherManager 来管理全部的 Watcher。当某个 Znode 的数据发生变动时，WatchManager 将触发相应的 Watcher，并通过与订阅该 Znode 的 ZooKeeper 客户端的 socket 进行通信。随后，客户端的 Watch 管理器将触发相关的 Watcher 回调，以执行相应的处理逻辑，从而完成整个数据发布/订阅流程。
https://pic3.zhimg.com/v2-d867fe738667c467fb14c0bd2ebde836_b.jpg进一步分析 WatchManager，成员变量 Watch2Path、WatchTables 内存占比高达 (18.88+9.47)/31.82 = 90%。
https://pic4.zhimg.com/v2-0759a79fbf47b017765cebbc3d7360e3_b.jpg而 WatchTables、Watch2Path 存储的是 ZNode 与 Watcher 正反映射关系，存储结构图所示：
https://pic1.zhimg.com/v2-cdd6f9cffffeab431870928406f79988_b.jpgWatchTables【正向查询表】HashMap>
场景：某个 ZNode 发生变化，订阅该 ZNode 的 Watcher 会收到通知。
逻辑：用该 ZNode，通过 WatchTables 找到对应的全部 Watcher 列表，然后逐个发通知。
Watch2Paths【逆向查询表】
HashMap
场景：统计某个 Watcher 到底订阅了哪些 ZNode。
逻辑：用该Watcher，通过 Watch2Paths 找到对应的全部 ZNode 列表。
Watcher 本质是 NIOServerCnxn，可以理解成一个连接会话。如果 ZNode、和 Watcher 的数量都比较多，而且客户端订阅 ZNode 也比较多，甚至全量订阅。这两张 Hash 表记录的关系就会呈指数增长，最终会是一个天量！
当全订阅时，如图演示：
当 ZNode数量：3，Watcher 数量：2 WatchTables 和 Watch2Paths 会各有 6 条关系。
https://pic3.zhimg.com/v2-c82df093f5ae9bd7a14d4e8a2b4aff96_b.jpg当 ZNode数量：4，Watcher 数量：3 WatchTables 和 Watch2Paths 会各有 12 条关系。
https://pic2.zhimg.com/v2-a1d872241537ecc73e7f942c812fa849_b.jpg通过监控发现，非常的 ZK-Node。ZNode 数量大概有 20W，Watcher 数量是5000。而 Watcher 与 ZNode 的关系条数达到了 1 亿。
如果存储每条关系的需要 1 个 HashMap&Node(32Byte)，由于是两个关系表，double 一下。那么其它都不要计算，光是这个“壳”，就需要 2*10000^2*32/1024^3 = 5.9GB 的无效内存开销。
2.3 不测发现
通过上面的分析可以得知，需要避免客户端出现对全部 ZNode 进行全面订阅的情况。然而，实际情况是，很多业务代码确实存在这样的逻辑，从 ZTree 的根节点开始遍历全部 ZNode，并对它们进行全面订阅。
大概能够说服一部分业务方进行改进，但无法欺压约束全部业务方的利用方式。因此，办理这个问题的思路在于监控和预防。然而，遗憾的是，ZK 本身并不支持这样的功能，这就需要对 ZK 源码进行修改。
通过对源码的跟踪和分析，发现问题的根源又指向了 WatchManager，而且细致研究了这个类的逻辑细节。颠末深入理解后，发现这段代码的质量好像像是由应届结业生编写的，存在大量线程和锁的不适当利用问题。通过检察 Git 记录，发现这个问题可以追溯到 2007 年。然而，令人振奋的是，在这一段时间内，出现了 WatchManagerOptimized（2018），通过搜索 ZK 社区的资料，发现了 ，即在 2011 年，ZK 社区就已经意识到了大量 Watch 导致的内存占用问题，并最终在 2018 年提供了办理方案。正是这个WatchManagerOptimized 的功劳，看来 ZK 社区早就进行了优化。
https://pic1.zhimg.com/v2-7f81af00f17f4b911935f7a6fc38b900_b.jpg有趣的是，ZK 默认情况下并未启用这个类，即使在最新的 3.9.X 版本中，默认仍然利用 WatchManager。大概是因为 ZK 年代久远，渐渐地人们对其关注度降低了。通过询问阿里的同事，确认了 MSE-ZK 也启用了 WatchManagerOptimized，这进一步证实了得物技术团队关注的方向是正确的。
2.4 优化探索
锁的优化
在默认版本中，利用的 HashSet 是线程不安全的。在这个版本中，相关操作方法如 addWatch、removeWatcher 和 triggerWatch 都是通过在方法上添加了 synchronized 重型锁来实现的。而在优化版中，采用了 ConcurrentHashMap 和 ReadWriteLock 的组合，以更精细化地利用锁机制。这样一来，在添加 Watch 和触发 Watch 的过程中能够实现更高效的操作。
https://pic4.zhimg.com/v2-810f497099bcb6d61a3099fdd9241e2b_b.jpg存储优化
这是关注的重点。从 WatchManager 的分析可以看出，利用 WatchTables 和 Watch2Paths 存储效率并不高。如果 ZNode 的订阅关系较多，将会额外消耗大量无效的内存。
感到惊喜的是，WatchManagerOptimized 在这里利用了“黑科技” -> 位图。
利用位图将关系存储进行了大量的压缩，实现了降维优化。
Java BitSet 主要特点：
[*]空间高效：BitSet 利用位数组存储数据，比尺度的布尔数组需要更少的空间。
[*]处理快速：进行位操作（如 AND、OR、XOR、翻转）通常比相应的布尔逻辑操作更快。
[*]动态扩展：BitSet 的大小可以根据需要动态增长，以容纳更多的位。
BitSet 利用一个 long[] words 来存储数据，long 类型占 8 字节，64 位。数组中每个元素可以存储 64 个数据，数组中数据的存储顺序从左到右，从低位到高位。比如下图中的 BitSet 的 words 容量为 4，words 从低位到高位分别表示数据 0~63 是否存在，words 的低位到高位分别表示数据 64~127 是否存在，以此类推。其中 words = 8，对应的二进制第 8 位为 1，说明此时 BitSet 中存储了一个数据 {67}。
https://pic1.zhimg.com/v2-65621b2c3b265c68da7a186619810b04_b.jpgWatchManagerOptimized 利用 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，而是用位图来存储位图索引值。
https://pic3.zhimg.com/v2-0fedac43d1faedef8210116d5d65f412_b.jpg用 1W 的 ZNode，1W 的 Watcher，极端点走全订阅（全部的 Watcher 订阅全部的 ZNode），做存储效率 PK：
https://pic2.zhimg.com/v2-044698c2481a9882be698ecbce051365_b.jpg可以看到 11.7MB PK 5.9GB，内存的存储效率相差：516 倍。
逻辑优化
https://pic3.zhimg.com/v2-7aaed39ee7039f3e8a7f9436360ed62a_b.jpg添加监视器：两个版本都能够在常数时间内完成操作，但是优化版通过利用 ConcurrentHashMap 提供了更好的并发性能。
https://pic2.zhimg.com/v2-6ccff7fc1605fa77b2de62fe32334b49_b.jpg删除监视器：默认版可能需要遍历整个监视器聚集来找到并删除监视器，导致时间复杂度为 O(n)。而优化版利用 BitSet 和 ConcurrentHashMap，在大多数情况下能够快速定位和删除监视器，O(1)。
https://pic1.zhimg.com/v2-acaf5bf7bd3aaeb05b9b6e57a46eac84_b.jpg触发监视器：默认版的复杂度较高，因为它需要对每个路径上的每个监视器进行操作。优化版通过更高效的数据结构和减少锁的利用范围，优化了触发监视器的性能。
https://pic2.zhimg.com/v2-24a85ab63dd9bfef741bc973ca5e38f5_b.jpg3. 性能压测
3.1 JMH 微基准测试
ZooKeeper 3.6.4 源码编译， JMH micor 压测 WatchBench。
https://pic1.zhimg.com/v2-0ba39105908d4db5a700b4fb38c40068_b.jpgpathCount：表示测试中利用的 ZNode 路径数目。watchManagerClass：表示测试中利用的 WatchManager 实现类。
watcherCount：表示测试中利用的观察者（Watcher）数目。
Mode：表示测试的模式，这里是 avgt，表示平均运行时间。
Cnt：表示测试运行的次数。
Score：表示测试的得分，即平均运行时间。
Error：表示得分的毛病范围。
Units：表示得分的单位，这里是毫秒/操作（ms/op）。
[*]ZNode 与 Watcher 100 万条订阅关系，默认版本利用 50MB，优化版只需要 0.2MB，而且不会线性增加。
[*]添加 Watch，优化版（0.406 ms/op）比默认版（2.669 ms/op）提拔 6.5 倍。
[*]大量触发Watch ，优化版（17.833 ms/op）比默认版（84.455 ms/op）提拔 5 倍。
3.2 性能压测
接下来在一台呆板 (32C 60G) 搭建一套 3 节点 ZooKeeper 3.6.4 利用优化版与默认版进行容量压测对比。
场景一：20W znode 短路径
Znode 短路径: /demo/znode1
https://pic3.zhimg.com/v2-4aa575877338dd2766370c4ef51497ca_b.jpg场景二：20W znode 长路径
Znode 长路径: /sentinel-cluster/dev/xx-admin-interfaces/lock/_c_bb0832d5-67a5-48ab-8fe0-040b9ddea-lock/12
https://pic2.zhimg.com/v2-9c568f94ab84d0d903a7a82dfebafc9d_b.jpg
[*]Watch 内存占用跟 ZNode 的 Path 长度有关。
[*]Watch 的数量在默认版是线性上涨，在优化版中表现非常好，这对内存占用优化来说改善非常明显。
3.3 灰度测试
基于前面的基准测试和容量测试，优化版在大量 Watch 场景内存优化明显，接下来开始对测试环境的 ZK 集群进行灰度升级测试观察。
第一套 ZooKeeper 集群 & 收益
https://pic4.zhimg.com/v2-ef62a16dde01945d7875cb05dc1cc51b_b.jpg默认版
https://pic2.zhimg.com/v2-6c09cb5f69dcb7b6dd4e8c38f2633b71_b.jpg优化版
https://pic1.zhimg.com/v2-ed83403066d9f6c1267e5cac5b29a01c_b.jpghttps://pic3.zhimg.com/v2-ac4cc1f62b74c4dc69f876273e807c82_b.jpg效果收益：
[*]election_time (选举耗时)：降低 60%
[*]fsync_time (事务同步耗时)：降低 75%
[*]内存占用：降低 91%
第二套 ZooKeeper 集群 & 收益
https://pic1.zhimg.com/v2-ca53e1829fd3da584872cda786e0e9a4_b.jpghttps://pic2.zhimg.com/v2-cc21856a79536d3972c2aeaad53097dd_b.jpghttps://pic4.zhimg.com/v2-79257914cdb7ba845851473c32c37983_b.jpghttps://pic3.zhimg.com/v2-c0036c7943bc5dd74796ebafe2dbcd16_b.jpg效果收益：
[*]内存：变动前 JVM Attach 响应无法响应，采集数据失败。
[*]election_time（选举耗时）：降低 64%。
[*]max_latency（读延迟）：降低 53%。
[*]proposal_latency（选举处理提案延迟）：1400000 ms --> 43 ms。
[*]propagation_latency（数据的传播延迟）：1400000 ms --> 43 ms。
第三套 ZooKeeper 集群 & 收益
https://pic3.zhimg.com/v2-aea64e236c81dbeb995c8375fc971a66_b.jpg默认版
https://pic2.zhimg.com/v2-6804d577ef2f56f0ec76cde802c16261_b.jpg优化版
https://pic2.zhimg.com/v2-a0646e017f14fe8871ae7efba3ba46b5_b.jpghttps://pic3.zhimg.com/v2-313a3d764977ba19719fd2071d15afb2_b.jpg效果收益：
[*]内存：节省 89%
[*]election_time（选举耗时）：降低 42%
[*]max_latency（读延迟）：降低 95%
[*]proposal_latency（选举处理提案延迟）：679999 ms --> 0.3 ms
[*]propagation_latency（数据的传播延迟）：928000 ms--> 5 ms
4. 总结
通过之前的基准测试、性能压测以及灰度测试，发现了 ZooKeeper 的 WatchManagerOptimized。这项优化不仅节省了内存，还通过锁的优化显著提高了节点之间的选举和数据同步等指标，从而增强了 ZooKeeper 的一致性。还与阿里 MSE 的同学进行了深度交流，各自在极端场景模拟压测，并达成了一致的见解：WatchManagerOptimized 对 ZooKeeper 的稳固性提拔显著。总体而言，这项优化使得 ZooKeeper 的 SLA 提拔了一个数量级。
ZooKeeper 有很多配置选项，但大部分情况下不需要调整。为提拔体系稳固性，发起进行以下配置优化：
[*]将 dataDir（数据目录）和 dataLogDir（事务日志目录）分别挂载到差别的磁盘上，并利用高性能的块存储。
[*]对于 ZooKeeper 3.8 版本，发起利用 JDK 17 并启用 ZGC 垃圾接纳器；而对于 3.5 和 3.6 版本，可利用 JDK 8 并启用 G1 垃圾接纳器。针对这些版本，只需要简单配置 -Xms 和 -Xmx 即可。
[*]将 SnapshotCount 参数默认值 100,000 调整为 500,000，这样可以在高频率 ZNode 变动时显著降低磁盘压力。
[*]利用优化版的 Watch 管理器 WatchManagerOptimized。
原文链接
本文为阿里云原创内容，未经允许不得转载。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]