京公网安备11010502063487号Curator 5.7.1 的 CuratorCache 实测:1000 个节点 98 ms 加载完成;读缓存 0.14 µs vs 直读 ZooKeeper 119 µs(约 826 倍);事件类型与延迟;200 次快速更新合并成 150 次事件;断网 6 s 期间缓存一直返回旧值、恢复后 0.1 s 追上。
Curator DistributedAtomicLong 实测:10 线程 1000 次 increment 最终值 1000;重试只允许 1 次时 672 次 succeeded()=false 且不抛异常(最终值 328);PromotedToLock 保证 1000/1000;吞吐随线程数从 238 降到 131 次/s;顺序节点发号 1142 个/s。
Curator 重试策略实测:服务端不可用时 6 种策略放弃前的耗时(2.3–7.9 s)、策略被 main 与 Curator-Framework 两条线程各调用一遍、指数退避的间隔带随机性;服务端重启约 3 s 期间 RetryNTimes(1,100) 失败,其余 3 种成功。
go-zookeeper/zk v1.0.4 在真实 ZooKeeper 3.9.6 上的实测:错误为包级变量、watch 是一次性 channel(200 次更新收到 170 次事件)、64 goroutine 并发 35.9 倍、Multi 原子、自带锁 200/200、服务端不可用时调用立即失败而不是等待。
读 ZooKeeper 3.9.6 的 FastLeaderElection 源码并逐条验证:totalOrderPredicate 用反射穷举 64 组与源码规则一致;观察者的选票全为 MIN_VALUE;finalizeWait=200 ms 使选举耗时 217–227 ms;通知超时按 200→400→800 ms 指数退避。
读 ZooKeeper 3.9.6 的 WatchManager 与 DataTree 源码并逐条验证:Set 去重(重复注册 100 次只计 1)、触发即移除、连接关闭时清理、持久递归 watch 不被移除并覆盖子孙节点、delete 时 supress 使同一 watcher 只收到一个通知、createNode 更新父节点 cversion 与 pzxid。
真实运行 Dubbo 3.3.6 的 ZooKeeper 注册中心并读 ZookeeperRegistry 源码:接口级与应用级两套注册节点、mapping 与 metadata;默认 session 60 s 被服务端截到 20 s(16 s 后节点消失,但 kill -9 时消费者 0 次失败);session=3000 约 3 s;SIGTERM 注销 0.02 s。
本机真实用composed_of组合两个Component Template，验证正交配置如何叠加，以及冲突设置时数组后面的覆盖前面的顺序仲裁规则。
本机真实验证多索引alias直接写入会被拒绝，必须用is_write_index消歧，而查询操作天然能跨所有成员索引搜索不受此限制。
本机真实触发Rollover，验证它自动创建命名递增的新索引并自动完成write_index的切换，应用层写入完全无感知。
本机真实验证字段类型无法原地修改，用_reindex搬迁到新索引，并踩中reindex完立刻查count是0没有自动refresh的真实的坑。
本机真实让两个update_by_query并发抢同一批文档，用严丝合缝互补的updated/version_conflicts数字证明它底层是逐条乐观并发写回。