1. 临时节点的生命周期由“会话”说了算不由“连接”说了算先丢一个反直觉的结论当你的客户端和 ZooKeeper 之间的 TCP 连接断开时临时节点并不会像很多人以为的那样立刻消失。它什么时候被删取决于会话Session的存活状态而不是连接状态。ZooKeeper 的临时节点删除机制核心就一句话会话结束节点删除连接断开只是会话可能走向结束的触发条件并不是删除动作的直接原因。这个机制我见过太多人理解反了——尤其是第一次做分布式锁、用临时节点做服务注册的时候节点删慢了觉得系统有问题节点删快了又觉得是 ZooKeeper 抽风。1.1 先区分两个容易混淆的词连接与会话“连接”是客户端和 ZooKeeper 服务器之间那条实际的 TCP 链路。它可能因为网络抖动、服务器重启、客户端进程崩溃而随时断掉。“会话”则是一个逻辑概念可以类比成你在某个网站上的登录态。你手机的网络断了TCP 连接没了但服务端的登录态不会立刻销毁只有退出登录或者登录态超过有效时间服务端才会真正把你踢出系统。ZooKeeper 的会话就是这个道理连接只是会话的载体会话本身有独立的生命周期。在 ZooKeeper 里创建一个临时节点时客户端其实是在说“这个节点要挂在当前会话名下”。服务器收到创建请求后会把节点的 metadata 里记上当前会话的 sessionId而不是把它简单理解成“哪个 IP 的客户端创建的”。所以判断一个临时节点到底还存不存在唯一的依据就是它的 sessionId 对应的会话是否还有效。1.2 session ID 才是临时节点的“归属凭证”用原生 Java 客户端创建临时节点时你可以清楚地看到 sessionId 的存在ZooKeeper zk new ZooKeeper(127.0.0.1:2181, 5000, event - { // 监听处理 }); long sessionId zk.getSessionId(); byte[] passwd zk.getSessionPasswd(); String path zk.create( /demo/ephemeral, hello.getBytes(), ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL ); System.out.println(sessionId Long.toHexString(sessionId)); System.out.println(created path path);这个 sessionId 就是临时节点的“主人身份证”。服务端会维护一张映射关系哪个 sessionId 创建了哪些临时节点。当这个 session 过期时服务端一次性把这张映射关系里的所有临时节点全删掉当 session 还活着时哪怕你客户端和服务器之间的 TCP 已经断了整整 5 分钟只要会话没有过期节点依然会躺在数据树上。1.3 不立刻删其实是刻意设计的容错策略很多初学者会问连接都断了节点留着还有什么意义这不是 bug而是 ZooKeeper 的容错设计。分布式环境下网络抖动是常态一个客户端可能每隔几秒就会碰到一次连接闪断。如果每次断连都立刻把临时节点删掉那么分布式锁会频繁误判、服务注册信息会疯狂抖动、Leader 选举会隔三差五重新来一轮。ZooKeeper 希望达成的效果是短暂断连时客户端可以通过重连恢复同一个会话节点继续保留只有长时间失联服务端才认为这个客户端真的“没了”然后才走删除流程。删除机制的存在是为了保证“当客户端死亡时它的临时痕迹不会被永远留着”而延迟删除是为了给“假死”的客户端留出恢复时间。所以当你看到“临时节点在连接断开后没有立即删除”的现象时不要第一时间怀疑 ZooKeeper 出问题了先搞清楚会话还活没活。2. 从连接断开到会话过期临时节点删除背后的判定链路要真正回答“连接断开后立即删除吗”得把服务端那套判定链路讲清楚。临时节点的删除不是客户端发起的也不是连接断开这个动作触发的而是服务端的会话过期检查机制“发现”会话超时后主动执行的清理。2.1 服务端的清理流程ZooKeeper 服务端有一个组件专门负责跟踪会话叫 SessionTracker。集群模式下会话的过期判定主要由 Leader 负责统筹单机模式下就是当前这台服务器自己判断。整个流程大致是这样客户端建立连接并创建会话后服务端会根据 sessionTimeout 给这个会话算出一个“下一次过期时间”。每次客户端发来请求或心跳服务端都会刷新这个过期时间相当于把会话的倒计时重置。服务端每隔一个 tickTime默认 2000ms检查一次看看哪些会话的过期时间已经过了。一旦某个会话过了最后期限服务端把会话标记为 expired然后将这个会话关联的所有临时节点批量删除。如果此时客户端重新连上来会收到 SessionExpiredException表示旧会话已经不存在了需要重新建会话。关键点在于删除动作是“批量”的不是删一个节点单独走一条命令。服务端拿到过期会话的 sessionId直接查这个 sessionId 关联的临时节点集合整体移除所以临时节点删除的效率很高不会因为你创建了几万个临时节点就拖垮服务端。2.2 倒计时从“最后一次心跳/请求”开始算这里有一个特别容易被忽略的细节会话的倒计时不是从“客户端感知到断连”那一刻开始的而是从服务端“最后一次收到这个会话的请求或心跳”那一刻开始算的。假设 sessionTimeout 设的是 10 秒客户端每 3 秒发一次心跳。如果网络在客户端刚发完一次心跳后就断了那么服务端看到这个会话的下一次过期时间大概还剩 7 秒左右也就是说连接断开后最多等 7 秒就会发生删除如果网络在客户端还没来得及发下一次心跳时就断了那服务端可能已经等了接近 3 秒没收到任何请求这时过期时间只剩 4 秒左右那么断开后大约 4 秒就会被删。所以“连接断开后立即删除吗”的准确答案应该是不会立即删除删除发生在会话过期判定之后实际等待时间在几秒到 sessionTimeout 之间浮动取决于会话剩余的有效时间。2.3 客户端状态机是怎么切换的搞清楚服务端视角后再看客户端状态机就会清晰很多。ZooKeeper 客户端的连接状态通常有这几种CONNECTING正在寻找服务器建立连接。CONNECTED已经连上 ZooKeeper会话有效。DISCONNECTED连接断开但会话信息还保存在客户端本地。EXPIRED会话已经被服务端判定过期。CLOSED客户端主动关闭连接和会话一起结束。对应到临时节点上DISCONNECTED 状态下节点可能还活着因为会话还没过期。EXPIRED 状态下节点一定已经没了因为服务端已经删完。CLOSED 状态下节点会被立即清掉因为 close() 会主动向服务端发送关闭会话的请求。不少人在代码里自定义了一个连接状态监听器一旦收到 DISCONNECTED 就去查临时节点发现节点还在于是觉得很奇怪。其实按上面的状态机这完全是正常现象DISCONNECTED 不代表会话结束只是连接层面断了。2.4 用一条命令验证“断开不立即删”想亲手验证这个机制不需要写复杂代码。最简单的办法是开两个 ZooKeeper 客户端会话一个创建临时节点另一个观察节点状态。会话 AzkCli.sh -server 127.0.0.1:2181 [zk: localhost:2181(CONNECTED) 0] create -e /tmp/test-node hello Created /tmp/test-node会话 BzkCli.sh -server 127.0.0.1:2181 [zk: localhost:2181(CONNECTED) 0] get /tmp/test-node hello此时把会话 A 的进程直接 kill -9而不是执行 quit 或 close。kill -9 意味着 TCP 连接被系统层面强制断开没有机会发送任何优雅关闭的请求。回到会话 B 立刻查看节点你会发现节点还在等 sessionTimeout 过了以后再去查节点才消失。注意用 zkCli 默认的 timeout 可能比较长建议在 zoo.cfg 里把 minSessionTimeout 调小一点再试比如设成 4000ms否则要干等几十秒。这个实验非常有价值做完一次你就会彻底明白临时节点删除机制的触发点是“会话过期”不是“连接断开”。3. 五种断开场景的实测结果有些立刻删有些等半天既然临时节点的删除取决于会话状态那么不同“断开”方式就会产生完全不同的结果。下面这五种场景是我在做分布式系统时反复遇到的也是面试里常被拿出来问的点。3.1 客户端主动 close最接近“立即删除”的场景当客户端调用zk.close()时客户端会主动向服务端发送一个 closeSession 请求。服务端收到后会马上关闭当前会话并把该会话关联的临时节点全部删除。这个删除过程是否“立即”在正常网络条件下从发起 close 到节点消失通常只有几百毫秒。但要注意如果关闭之前连接已经断了客户端连不上服务器close() 可能只是在本地把会话标记为关闭并不会发送任何消息。这种情况下临时节点依然要等服务端判定会话过期才会被删不是你调了 close() 就立刻生效。3.2 网络闪断后快速重连会话复活节点保留这是最常见的场景交换机抖动、容器重启、网络路由短暂不可达客户端和 ZooKeeper 的连接断了几百毫秒甚至几秒客户端自动重连成功。因为重连速度远小于 sessionTimeout服务端并没有等到会话过期。客户端重连时会带上原来的 sessionId 和 passwd服务端校验会话仍然有效就把这个会话“认领”回来。此时原来创建的临时节点一个都不丢watch 也大概率还能继续用。这也是为什么 ZooKeeper 官方建议客户端要做自动重连而不是手动捕获异常后重新 new 一个 ZooKeeper。只有复用同一个 session临时节点才能保持连续。3.3 进程被强杀或断网超过超时延迟删除客户端进程被 kill -9或者网络断开超过 sessionTimeout服务端收不到任何心跳最终会把会话标记为 expired然后删除该会话下的所有临时节点。这个“延迟”不是固定的它取决于你的 sessionTimeout 配置以及断连前最后一次心跳的时间点。如果你把 sessionTimeout 配得很大比如 60 秒那么进程死了 1 分钟节点才被清理掉。对于依赖临时节点做服务发现的业务来说这 1 分钟里流量可能还会打到一个已经死掉的服务实例上。要么把超时配小要么在业务层再加一层主动探活机制。3.4 服务端集群故障删除时机变得不确定如果 ZooKeeper 服务器本身出现问题比如某台节点宕机、集群进入选主流程那么临时节点的命运就和“客户端连接断开”关系不大了关键看会话能否在超时前被新选出的 Leader 接管。客户端只要能在会话过期前重连到集群中的另一台服务器并携带正确的 sessionId 和 passwd旧会话通常可以延续临时节点保留。如果客户端一直连不上或者重连时会话已经过期那节点就会被清理。在这个场景里临时节点的删除时机受到服务端可用性影响可能比正常情况更晚因为选主期间服务端本身也在停顿会话过期检查可能被延后。3.5 客户端 GC 停顿导致“假死”最容易被误判的情况还有一个隐蔽场景客户端的 TCP 连接看起来没断JVM 也还活着但发生了一次长时间 Full GC整个进程阻塞了几十秒心跳线程根本没机会发 ping。服务端只看“这个会话是否有心跳进来”不会管你进程是不是还活着超过 sessionTimeout 照样判死、照样删节点。我见过不少生产事故就是这么来的明明客户端进程没退出却因为 GC 停顿导致临时节点被删进而触发分布式锁转移新的 Leader 选出来之后旧的客户端 GC 恢复又认为自己还是 Leader两边同时写数据。这个问题的根源不在 ZooKeeper而在误以为“TCP 连接不断 会话必然有效”。3.6 五种场景对比场景连接状态会话状态临时节点行为客户端最终感知主动 close()断开立即结束立刻删除本地关闭无后续通知网络闪断后快速重连短暂断开会话延续节点保留Connected/SyncConnected进程强杀/断网超时断开服务端判过期超时后删除重连后收到 SessionExpired服务端集群故障不断尝试可能迁移或过期视重连时效和选主进度而定可能恢复也可能过期客户端 GC 停顿表面正常心跳停止后被判过期超时后删除且无主动通知恢复后被告知会话已过期这张表写完你应该能感觉到临时节点的删除机制本质上是“会话租约”机制而不是“连接监控”机制。想准确预测删除时机先回答一个问题这个会话还能不能靠心跳续命4. 超时值、心跳频率、重连策略影响删除速度的隐藏参数既然删除时机由会话过期决定那么在 ZooKeeper 里sessionTimeout 就成了最核心的旋钮。但真正落地时还需要理解心跳频率和它之间的关系否则你配的参数可能根本没按你的预期生效。4.1 sessionTimeout 的配置边界服务端并不是完全尊重客户端传上来的 sessionTimeout。zoo.cfg 里有这么两个参数minSessionTimeout默认 2 * tickTimetickTime 通常为 2000ms所以最小 4000ms。maxSessionTimeout默认 20 * tickTime也就是 40000ms。如果客户端在创建连接时传入的 sessionTimeout 小于最小值服务端会强制拉高到 minSessionTimeout如果大于最大值则被压低到 maxSessionTimeout。很多人不知道这个钳制逻辑客户端配了 10 秒结果因为服务端最小超时被调成了 15 秒实际生效的是 15 秒节点就比预想中多活了 5 秒。排查“节点迟迟不删”的问题时第一件事就是确认实际生效的 sessionTimeout 是多少可以先看服务端日志或者直接调小参数测试。4.2 心跳 ping 的发送频率ZooKeeper 客户端不会真的每隔 sessionTimeout 秒才发一次心跳而是按 sessionTimeout / 3 的频率主动发送 ping。假设 sessionTimeout 是 30 秒客户端大约每 10 秒发一次心跳。这个设计是为了让服务端能“提前”知道客户端还活着留出足够的时间余量避免网络稍有延迟就误判过期。但这也意味着断网发生后服务端感知到异常的最短时间窗口其实已经过去了 sessionTimeout 的 1/3。如果 sessionTimeout 设成 10 秒那断网后最快可能 3~4 秒就被判死设成 60 秒最短也要 20 秒左右才会有过期判定。所以不要指望把 sessionTimeout 设得很小来换取“秒级删除”。即使设成 4000ms 的最小值删除也可能要等 1~2 秒这已经是 ZooKeeper 的物理下限。4.3 重连失败与 SessionExpiredException客户端重连时如果会话还没过期服务端会接受旧 sessionId如果已经过期服务端会返回 SessionExpiredException。此时旧的临时节点已经被删客户端继续创建节点会用新的 sessionId之前的 watch、节点全部作废。从代码层面看最容易踩的坑是这样的ZooKeeper zk new ZooKeeper(server:2181, 10000, watcher); // 重试逻辑里再次 new ZooKeeper while (true) { try { zk.getData(/lock, false, null); break; } catch (SessionExpiredException e) { // 直接 new 一个新的 ZooKeeper旧会话没了 zk new ZooKeeper(server:2181, 10000, watcher); } catch (ConnectionLossException e) { // 连接丢失继续重试 } }这个写法的问题在于如果旧会话已经过期你虽然 new 了新客户端但业务层面的分布式锁信息、注册的临时节点也全都丢了不能简单地继续执行。SessionExpiredException 意味着整个上下文需要重置而不是重连即可。4.4 我的经验值生产环境超时怎么设结合我自己的实践给出一个比较稳妥的参考范围服务注册/服务发现场景sessionTimeout 建议 10~30 秒。太短会让注册信息在上线发布时频繁抖动太长会让死掉的实例继续接收流量。分布式锁场景如果业务临界区执行时间很短可以设 10 秒左右如果临界区本身要跑十几秒必须远大于执行时间否则锁会还没执行完就被释放。客户端本身有 Full GC 风险的场景先解决 GC不要只靠调大 sessionTimeout 遮羞。调大到 30~60 秒只能缓解不是根治。另外客户端和服务端之间最好在同一个网络域内跨机房时 RTT 变大心跳和请求传输时间都要考虑进余量否则极容易发生“网络慢导致会话过期”的假死事故。5. 临时节点消失后业务方如何第一时间感知很多场景里我们不只关心“节点什么时候被删”还关心“别人怎么知道节点被删了”。ZooKeeper 的 watch 机制就是为此设计的但有几个坑不提前说清楚生产环境里一定会踩。5.1 NodeDeleted 事件是一次性的ZooKeeper 的 watch 和很多消息系统的订阅不太一样它默认是一次性触发。你注册了一个 watcher当节点数据变化、节点删除、子节点变化时客户端会收到对应的事件但收到之后这个 watcher 就失效了如果还想继续监听必须再次注册。以监听临时节点删除为例public void watchNode(String path) throws Exception { ZooKeeper zk new ZooKeeper(127.0.0.1:2181, 10000, event - { if (event.getType() Event.EventType.NodeDeleted) { System.out.println(node deleted: event.getPath()); // 需要重新注册 watcher否则后续节点变化不会再通知 watchNode(path); } }); // 先设置 watch再读节点节点不存在时会抛 KeeperException.NoNodeException zk.exists(path, true); }这里有个细节如果节点已经不存在exists调用本身会抛异常无法注册 watcher。所以合理的做法是先看exists是否返回 nullnull 也要继续注册 watch因为目标节点可能在稍后被创建出来。5.2 临时节点在分布式锁里的角色临时节点最经典的用途就是分布式锁。客户端创建临时节点 /lock谁创建成功谁就拿到锁客户端崩溃后临时节点被服务端清理其他客户端通过 watch 感知到节点删除再去抢锁。但要注意一个反直觉的点锁的“释放”依赖的是会话过期不是客户端进程退出瞬间。如果 sessionTimeout 是 30 秒你进程 kill -9 后其他客户端最多要等 30 秒才能抢到锁。对一些需要快速故障转移的业务来说这个等待可能是致命的。所以成熟的分布式锁客户端会设置一个较短的 sessionTimeout同时又不能让业务方法执行时间超过这个值。Curator 的 InterProcessMutex 就是基于临时顺序节点实现的内部会自动处理重连、过期等复杂状态强烈建议直接用 Curator而不是手写原生 ZooKeeper 客户端去处理所有边界情况。5.3 延迟删除带来的“孤岛”风险和脑裂问题临时节点延迟删除的另一个副作用是脑裂。A 节点本来是 Leader因为网络分区和 ZooKeeper 集群失联sessionTimeout 过后服务端把 A 的临时节点删掉B 节点通过 watch 感知到 Leader 消失选举自己成为新 Leader。但 A 节点并没有真正死掉它还在继续对外提供服务在自己的认知里依然是 Leader。这个瞬间两个“Leader”同时存在就叫脑裂。ZooKeeper 的临时节点机制只能保证“Leader 失联后最终会释放锁”不能保证“旧 Leader 真的停下来”。解决脑裂的标准做法是在业务层引入 fencing token也就是带版本的令牌。每次选举成功后生成一个新 token后续写数据必须携带当前 token旧 Leader 即使以为自己还是 Leader它的 token 也已经过期写入会被拒绝。不要幻想靠临时节点机制本身来防脑裂它只负责“租约到期”不负责“租赁人自愿搬家”。5.4 该用什么兜底策略临时节点的删除不是实时的业务上就不能假设“断连即清理”。我总结下来的兜底思路有三层让 sessionTimeout 匹配业务可接受的故障转移时间。在锁或选举场景加 fencing token防止旧主和新主同时写。对关键状态再叠加一层外部存储或数据库校验不要完全依赖 ZooKeeper 的临时节点作为唯一事实来源。6. 临时节点该删不删、不该删却删了排查实战与踩坑记录最后这部分是我最想写的因为平时遇到的问题绝大多数不是“理解机制”的问题而是“现象归因”的问题。下面两条症状非常典型排查思路可供参考。6.1 症状一进程已经退出临时节点却迟迟不消失服务实例被 kill -9 了但用 zkCli 去查看发现注册在 ZooKeeper 里的临时节点还活着。第一反应是服务端有问题其实大概率是这两个原因之一sessionTimeout 配置过大。比如线上配了 60 秒进程退出后节点当然要等 60 秒才被清理。客户端工具查的是错误的 ZooKeeper 集群。排查时先确认你连的是不是同一个集群别在测试环境里查生产数据这种尴尬我见过不止一次。用 zkCli 查看临时节点的归属可以这样确认[zk: localhost:2181(CONNECTED) 0] stat /service/instance-001 cZxid 0x100002c3 ctime Thu Jan 01 10:00:00 000 mZxid 0x100002c3 mtime Thu Jan 01 10:00:00 000 pZxid 0x100002c3 cversion 0 dataVersion 0 aclVersion 0 ephemeralOwner 0x300001a2b3c4d5e6关键字段是ephemeralOwner。如果这一行是 0x0说明当前节点是持久节点不是临时节点不要浪费时间排查会话问题。如果是一个非零的 sessionId说明确实是临时节点这时再去查这个 sessionId 对应的会话是否已过期。如果确认会话已过期但节点还在那就要看是不是服务端删除流程被阻塞了比如磁盘 IO 卡顿、ZooKeeper 进程堆内存不足导致 GC 时间过长清理动作迟迟没执行。6.2 症状二客户端进程明明活着节点却被删了这个症状更让人头疼因为从业务日志看进程没退出TCP 连接也显示正常但临时节点就是消失了。最典型的凶手是客户端 GC 停顿。我负责过一个调度系统每天凌晨会出现一次 Leader 闪断ZooKeeper 日志里频繁出现 session expire。查了很久最后定位到客户端在凌晨做全量内存数据清理触发了几次 Full GC单次停顿超过 60 秒。而当时的 sessionTimeout 只配了 10 秒客户端的心跳线程根本来不及发 ping服务端自然判定会话过期。解决措施有三步把 sessionTimeout 从 10 秒调到 30 秒给 GC 停顿留出余量。优化 GC 参数把 Full GC 的单次停顿压到 100ms 以内。业务侧引入 fencing token即使未来再发生类似误删也不会出现双主写冲突。这个事故给我的教训是临时节点是否存活本质上是“服务端听到心跳的能力”不是“客户端自我感觉是否健康”。任何阻塞心跳线层的因素都会让客户端在没死的情况下“被死亡”。6.3 排查临时节点相关问题的常用命令遇到问题时我的固定排查顺序是这样的# 1. 查看指定节点状态确认 ephemeralOwner zkCli.sh -server 127.0.0.1:2181 stat /service/instance-001 # 2. 查看整个命名空间下有哪些临时节点配合脚本遍历 ls /service # 3. 查看服务端会话相关信息ZooKeeper 3.6 支持更丰富的统计 zkServer.sh status echo mntr | nc 127.0.0.1 2181 # 4. 查看服务端日志搜索 session expired 关键字 grep session expired zookeeper.out如果数据量很大不要手动一个个 ls直接写一个小脚本递归遍历找出所有ephemeralOwner ! 0的节点再按 sessionId 分组这样能快速定位到“哪个会话还活着但节点不干净”。6.4 一次生产事故复盘GC 停顿与脑裂叠加那次事故最终的影响比预想严重因为临时节点被删后备节点立刻抢到了 Leader 标识开始接管写流量。而旧主节点在 GC 恢复后确认自己还持有原会话信息虽然已经过期没有做任何主动退出动作仍然继续写数据。两个写入方指向同一个存储导致数据出现大量覆盖和冲突。事后复盘时我发现当初的实现直接把 ZooKeeper 的临时节点当成了“绝对可靠的互斥锁”既没有检查会话是否过期也没有做 fencing 校验。正确做法应该是在每次写数据前都从 ZooKeeper 获取当前 Leader 的 token并且让数据写入方校验 token 的版本一旦发现自己的 token 不是最新的立刻降级为只读或退出。这也是我想强调的临时节点删除机制只是分布式协调的底层能力它不是银弹。理解它的边界比背下来“断连立即删除”这种错误结论重要得多。最后再分享一个自测方法如果你刚接手一个 ZooKeeper 相关项目想快速验证当前集群的临时节点清理行为不用写代码开两个 zkCli一个创建临时节点另一个用 stat 盯着 ephemeralOwner。一个用 quit 正常退出另一个用 kill -9 强杀分别观察节点删除时差这个实验做一遍后你大概率会对整个临时节点会话机制有更直观的判断。