bigywater.tech
ZooKeeper · 29

Observer 节点实战

observer 的价值在于「读扩展」和「不拖累写」:它们不投票,所以增加 observer 不会改变多数派。这篇验证几个实战里最关心的点:读是否真的不进 leader、observer 故障对写的影响、离线后怎么追上。

+1 个包
连在 observer 读 2000 次,leader 多收到的包数
写入不受影响
2 个 observer 同时停掉,投票节点仍能写
557 ms
离线期间错过 2000 个事务的 observer 重启后追上的时间(DIFF)

读扩展

实测 · 本机执行输出
  leader 的 zk_packets_received 增加 1

observer 故障

实测 · 本机执行输出
  停掉 2 个 observer 后通过投票节点写入:成功(38 ms 内完成)

离线后重启

实测 · 本机执行输出
  observer 重启后 557 ms 内 Zxid 追上 leader(0x1000007d8),Mode = observer
  leader 日志里发给它的同步方式: ['Sending DIFF zxid=0x0 for peer sid: 1', 'Sending DIFF zxid=0x1000007d8  for peer sid: 4']

分步演示

Observer 实战
本步的对象

    本文用到的工具与边界

    • 本机 macOS 27 / ZooKeeper 3.9.6(brew 安装的 jar,用 java -cp 直接启动自己的实例,OpenJDK 17 Temurin,JVM 堆 128 MiB)/ 本机回环端口 7300+,数据在临时目录;默认 tickTime=2000;计时用 time.perf_counter,数字每次运行会有小幅抖动。3 个投票节点 + 2 个 observer;读次数 2000;只测了一次
    • 没有验证:跨机房部署的实际收益、observer 数量很多时对 leader 发送开销的影响(第 28 篇看到有少量写延迟增加)、observer 读到的数据滞后程度
    京ICP备2026067502号-1京公网安备11010502063487号