京公网安备11010502063487号集群成员管理实测(静态配置):成员 = 每个节点 zoo.cfg 里的 server.N 列表 + myid;myid 不在列表里节点启动失败(退出码 1);成员列表不一致的节点无法加入;名单外的节点(myid=4)能以 follower 身份连上并同步,但不被算进多数派。
动态重配置实测:默认 reconfig 被禁用(Reconfig is disabled);开启 reconfigEnabled + dynamicConfigFile 后 config 命令返回成员与版本;reconfig -add 4 号节点后 639 ms 追上并成为 follower;reconfig -remove 后被移除的进程仍在运行。
集群扩容与缩容实测(动态配置):3 → 5 节点一条 reconfig 加入 2 个节点,20000 个 znode 用 snapshot, snapshot 同步,620 ms 追上;5 节点挂 2 个仍可写;reconfig -remove 4,5 缩回 3 节点后又只能容忍 1 个故障。
服务故障感知实测:临时节点 + 父节点 watch。正常退出 11 ms 被发现;kill -9 / 进程冻结要等会话超时(3 s → 3472 / 3321 ms,10 s → 9910 / 10385 ms)。
快照机制实测:每 snapCount/2~snapCount 个事务随机一次(504~963);20 万 znode 的快照 54 MiB、写 163 ms;后台快照不影响前台写延迟;gz 压缩使 10 万 znode 的快照从 27.0 MiB 降到 1.1 MiB(写 653 ms)。
快照频率与事务日志增长实测:不清理时 6 万次写产生 38 个快照(145 MiB)、81 个日志文件(表观 5 GiB、实占 13 MiB);PurgeTxnLog -n 3 清理后剩 3 个快照;autopurge 配置启动时即执行一次。
事务日志预分配与 fsync 实测:默认同步写 p50 3.02 ms,forceSync=no 降到 0.27 ms;fsync 慢时日志出现「fsync-ing the write ahead log … took 5ms」;异步写时平均批大小 15.0937,20000 个事务只多出 1044 次 fsync。
磁盘类型与提交延迟:macOS 上普通 os.fsync 中位 0.020 ms、F_FULLFSYNC 中位 2.96 ms;ZooKeeper 同步写 p50 3.01 ms(fsync 平均 2.1277 ms),去掉 fsync 后 0.32 ms——写延迟 ≈ fsync 耗时 + 约 0.3 ms。
磁盘满时的服务行为实测(24 MiB 小盘):写入 174 个 100 KiB znode 后失败,服务端因「No space left on device」自己退出(退出码 0);腾出 6 MiB 重启仍因写不下启动快照而失败(退出码 10,留下写了一半的快照);搬到 256 MiB 盘后数据完整。
文件损坏后的启动失败实测:最新快照截断 / 清零 → 回退旧快照 + 回放日志,数据不丢;无快照只剩日志 → 默认拒绝启动(trust.empty=true 放行);日志内容被改坏 → CRC check failed 拒绝启动;断电式撕裂写 → 丢弃不完整的最后一条正常启动;集群里清空数据目录可重新同步。
数据备份与恢复实测:写入进行中直接复制数据目录,5 次副本都能启动;只备份快照会丢快照之后的写入(3505 → 2983);集群里用旧备份恢复一个节点会被 leader 追平。
ZooKeeper 容量规划:由三组实测拟合堆占用 ≈ 每个 znode 629 字节 + 每个数据字节 1.04 字节,预测 10 万 × 500 字节为 109.7 MiB、实测 110.7 MiB(误差 0.9%);300 连接 + 6000 watch 另加 4.2 MiB。