Curator 使用方式

流式 API 与 namespace

实测 · 本机执行输出

  create EPHEMERAL_SEQUENTIAL 返回的路径(namespace 之内):/cfg/job-0000000001
  不带 namespace 的客户端 getChildren("/"):[zookeeper, app1];getChildren("/app1/cfg"):[job-0000000001, db]
  setData().withVersion(99) → BadVersionException
  create 已存在 → NodeExistsException

同步与后台

实测 · 本机执行输出

  同步 324 个/s(6.17 s);inBackground 25405 个/s(0.08 s);78.3 倍

对照kazoo的结果:Java 的 inBackground 和 Python 的 create_async 都是把请求在一个连接上流水线化,服务端按批处理。

短中断

实测 · 本机执行输出

  冻结发生在 +0.0 s,解冻在 +5.0 s
  listener 状态序列:[4.1s SUSPENDED, 5.9s RECONNECTED]
  中断期间发起的 setData(retry=ExponentialBackoffRetry):成功,发起后 5.6 s 返回(相对解冻 +0.9 s)
  会话 id 变了:false(旧 0x1000c96917c0002,新 0x1000c96917c0002)
  会话没有变:普通临时节点一直在(true),PersistentNode 的节点在(true)

用 kill -STOP 冻结 ZooKeeper 进程来模拟「服务端不响应」(TCP 连接保持,没有重置)。客户端在 2/3 会话超时后没读到响应才判定 SUSPENDED。

长中断

实测 · 本机执行输出

  冻结发生在 +0.0 s,解冻在 +12.0 s
  listener 状态序列:[0.0s CONNECTED, 4.1s SUSPENDED, 10.1s LOST, 12.1s RECONNECTED]
  中断期间发起的 setData(retry=ExponentialBackoffRetry):成功,发起后 11.7 s 返回(相对解冻 +0.0 s)
  会话 id 变了:true(旧 0x1000c96917c0003,新 0x1000c96917c0005)
  解冻后,旧会话的普通临时节点在服务端消失于 +7.0 s;PersistentNode 的节点属主变成新会话于 +7.0 s(相对解冻)

LOST 是客户端自己根据会话超时算出来的:服务端冻结时它既不能通知也不能确认。因此冻结期间可能出现「客户端认为会话丢了、服务端上旧会话的临时节点还在」的一小段窗口(这里实测 0 到 7 s)—— 不要假设旧会话的临时节点在新会话建立时已经消失。

分步演示

Curator 行为

本步的对象

本文用到的工具与边界

本机 macOS 27 / ZooKeeper 3.9.6(brew 安装的 jar,用 java -cp 直接启动自己的实例,OpenJDK 17 Temurin,JVM 堆 128 MiB)/ 本机回环端口 7300+,数据在临时目录;默认 tickTime=2000;计时用 time.perf_counter,数字每次运行会有小幅抖动。Curator 5.7.1(Maven Central,经代理下载)+ zookeeper 3.9.6 jar,OpenJDK 17;服务端中断用 kill -STOP / -CONT 模拟,会话超时 6 s;重试策略为 ExponentialBackoffRetry(200 ms, 最多 12 次, 最大睡眠 2 s)
没有验证:真正的网络分区(SIGSTOP 与断网并不完全等价)、旧会话临时节点滞留的根因、Curator 的 SessionFailRetryLoop / ConnectionStateErrorPolicy 等进阶选项、与 Spring Cloud 的整合(见第 106 篇)

下一篇 · ZOOKEEPER 93

Curator 分布式锁实现