bigywater.tech
ZooKeeper · 36

Leader 重新选举实测

leader 重新选举期间,应用会感觉到什么?这篇让一个写线程和一个读线程不停地发请求,杀 leader 5 次,记录它们遇到的最长中断。

445 ms
杀 leader 后写入的最长中断(中位)
432 ms
读也同样中断(没有 leader 时全部节点不服务)
不报错、只变慢
kazoo 同步调用在断线重连期间阻塞,而不是抛异常

不可用的时间窗

实测 · 本机执行输出 
   次      写不可用(ms)      读不可用(ms)      失败写次数
   1           386           386          0
   2           713           709          0
   3           494           496          0
   4           445           432          0
   5           379           375          1
  写不可用中位 445 ms(最小 379 / 最大 713);读不可用中位 432 ms

这是「最长两次成功请求之间的间隔」,包含客户端发现断线、重新连接到别的节点的时间,所以略大于第 34 篇里服务端侧的选举耗时。

分步演示

重新选举
本步的对象

    本文用到的工具与边界

    • 本机 macOS 27 / ZooKeeper 3.9.6(brew 安装的 jar,用 java -cp 直接启动自己的实例,OpenJDK 17 Temurin,JVM 堆 128 MiB)/ 本机回环端口 7300+,数据在临时目录;默认 tickTime=2000;计时用 time.perf_counter,数字每次运行会有小幅抖动。3 节点伪集群;每 10 ms 一次的同步写(创建节点)与读(exists);重复 5 次,每次把被杀的节点启动回来
    • 没有验证:Java 客户端 / Curator 的重试表现(第 92、97 篇)、客户端请求超时设置较小时的失败率、更大的集群、tickTime 调整后的中断时间
    京ICP备2026067502号-1京公网安备11010502063487号