1. 先把 ZooKeeper 放回它该在的位置ZooKeeper 这套东西我前后用了七八年从最早拿它当配置中心到后来做分布式锁、做选主、做元数据一致性协调中间踩过的坑比写过的代码多。很多人第一次接触 ZooKeeper 是被分布式协调服务这六个字劝退的——听起来玄乎实际上它干的事非常朴素帮一群互不相识的进程在一个大家都认可的、带顺序的、能感知变化的地方记录和交换少量状态。就这么一件事做扎实了就能撑起分布式系统里最难的那部分逻辑。这篇内容我想把 ZooKeeper 从头捋一遍数据模型长什么样、会话和 Watcher 有哪些反直觉的细节、ZAB 协议到底在保什么、集群怎么搭、客户端怎么写、哪些场景该用哪些场景坚决别用最后把我这些年遇到过的经典故障和排查手段摊开讲。适合已经写过几行分布式代码、被数据不一致锁失效会话过期这类问题折磨过的后端同学也适合刚接手一套老系统、发现里面藏着三节点 ZooKeeper 集群但完全不敢动的运维同学。零基础也能看我会把每个概念用生活化的方式讲清楚但涉及参数和配置的部分我会直接给数值你可以拿去对着改。先说结论性的判断省得你带着错误预期往下读ZooKeeper不是数据库别往里塞业务数据不是消息队列别拿 Watcher 当订阅通道推大量变更不是注册中心的万能答案服务规模上到几千个实例、心跳频繁的时候它会很难受。它最舒服的区间是数据量以 KB 计、节点数以百/千计、读远多于写、变更需要严格顺序、客户端需要感知变化。想清楚这个边界后面的所有设计取舍就都顺了。1.1 它到底解决了分布式里的哪一类问题分布式系统里有一类问题反复出现本质都是多个进程对一个共享状态达不成一致。比如配置改了十个服务实例怎么保证同时看到新值而且不会看到中间态某个任务只能有一个实例执行谁来做裁判主节点挂了剩下的节点怎么不打架地选出新主一个分布式队列如何保证每个元素只被消费一次。这些问题单独看各有各的解法但抽象出来都是同一件事——需要一个高可用的小型共识存储加上变更通知能力。ZooKeeper 就是把这个能力单独抽出来做成一个服务。它的价值不在于存储本身存的东西少得可怜而在于它把一致性这个最难的部分封装掉了你只需要调用 create/get/set/delete/watch 这几个语义简单的 API底下的选主、日志复制、崩溃恢复全由它负责。这一点非常关键你自己实现一套 Paxos/Raft 来做锁服务代码量不大但边界条件调试能要人命用 ZooKeeper你把复杂度外包给了一个经过十几年生产验证的组件。代价是有的。第一引入了一个新的强依赖组件它挂了你的业务逻辑里依赖协调的部分就停摆所以必须做降级设计。第二所有写操作都要过 Leader吞吐有天花板实测单集群写 QPS 通常在几千到一万多的量级具体看磁盘 fsync 能力和批次合并情况。第三客户端与服务端之间是长连接会话模型网络抖动会直接转化成会话事件需要业务代码正确处理。这三点是所有坑的源头后面会反复回到这里。1.2 数据模型一棵树四种节点一堆版本号ZooKeeper 的数据结构是一棵树学名叫 znode 树跟文件系统非常像每个节点用绝对路径标识比如/app/config/db节点可以挂子节点。但和文件系统不同的是ZooKeeper 的每个节点既能存数据又能有子节点不像文件系统里目录和文件是分开的。你可以理解成每个文件夹里都能塞一张小纸条。每个节点能存的数据有硬限制默认jute.maxbuffer是 1048575 字节也就是将近 1MB。但这只是协议层的上限不是使用建议。工程上我一律建议单个 znode 的数据控制在 1KB 以内超过 10KB 就该反思设计是不是错了。原因很直白每次写操作都要把这个节点的完整数据通过共识协议复制到多数派节点并落盘数据越大写延迟越高、网络和磁盘压力越大而且快照文件会膨胀得很快。我见过有人把整个服务的路由表序列化后塞进一个节点初期几百条没事长到几千条之后整个集群的写延迟从 3ms 涨到 40ms排查了两天才定位到。节点的类型分四种这个必须记牢因为选错类型会导致非常隐蔽的 bug类型创建命令参数生命周期典型用途持久节点 PERSISTENT默认显式删除才消失配置、元数据、目录结构临时节点 EPHEMERAL-e会话结束自动删除服务注册、存活探针、锁持有标记持久顺序节点 PERSISTENT_SEQUENTIAL-s显式删除才消失名字带自增序号队列、任务分配、全局有序编号临时顺序节点 EPHEMERAL_SEQUENTIAL-e -s会话结束自动删除名字带自增序号分布式锁排队、公平锁顺序节点的序号是父节点维度的自增计数存在父节点的cversion里格式是 10 位十进制左补零比如lock-0000000012。这里有个细节很多人不知道序号会被复用。如果创建了lock-0000000001到lock-0000000005然后全删掉父节点的 cversion 并不会回退但如果你把父节点本身删了重建计数就从 0 重新开始。所以千万不要把顺序号当成全局唯一 ID 用它只在同一父节点、同一生命周期内有序。再说版本号这是 ZooKeeper 实现乐观锁的基础。每个 znode 的 stat 结构里有一串字段我挑最常打交道的几个字段含义实用价值czxid创建该节点的事务 ID判断节点创建先后mzxid最后一次修改数据的事务 ID判断数据新旧pzxid最后一次修改子节点列表的事务 ID监听子节点变化时很有用version数据版本号每次 setData 加 1CAS 更新set -v参数cversion子节点版本号子节点增删时加 1顺序号来源也可做 CASaversionACL 版本号权限变更控制ephemeralOwner临时节点持有者的会话 ID持久节点为 0排查临时节点残留的关键线索dataLength/numChildren数据长度 / 子节点数快速评估节点是否过重version的用法是setData(path, data, expectedVersion)如果当前版本不等于 expectedVersion抛BadVersionException。这就是标准 CAS。做分布式配置更新、状态机迁移时这个机制能帮你避免后写覆盖先写的经典问题。我个人的习惯是任何可能被多个客户端并发修改的节点写入时一律带上 version宁可多写一层重试逻辑也不要裸写。2. 三个最容易被误读的核心机制ZooKeeper 的 API 只有六个create、delete、exists、getData、setData、getChildren。看起来简单到无聊但真正让人翻车的是藏在 API 背后的三个机制会话、Watcher、zxid 顺序。这三个东西的共同特点是——文档上写得很清楚但你只有踩过坑才会真正理解它在说什么。2.1 会话超时时间不是你说了算是协商出来的客户端连接 ZooKeeper 时会带一个sessionTimeout参数。很多人以为这就是最终的超时时间其实服务端会做一次夹取如果请求值小于minSessionTimeout默认2 * tickTime就用最小值大于maxSessionTimeout默认20 * tickTime就用最大值。假设tickTime2000那么可协商区间就是 4000ms 到 40000ms。客户端拿到的实际超时时间要通过getSessionTimeout()去查别自己脑补。会话的本质是客户端和服务端之间维持一个逻辑连接服务端为这个会话维护一个心跳计时器。客户端定期发 PING通常是超时时间的 1/3 间隔服务端收到就续命。如果服务端在超时时间内没收到任何请求就判定会话失效该会话创建的所有临时节点被删除所有 Watcher 被清理会话状态变成 Expired。这里有几个必须理解的推论第一会话失效是不可逆的。一旦收到SESSION_EXPIRED这个客户端对象就废了必须新建连接。Curator 之类的封装库会自动帮你重建但重建之后之前创建的临时节点全没了需要用ConnectionStateListener重新注册。我见过最典型的 bug 是服务注册代码只在启动时create一次临时节点会话过期重连后没有重新注册结果这个实例在注册中心里凭空消失了但进程还活着流量再也打不进来。第二超时时间设太短是自找麻烦。生产环境常见的坑是设 3 秒、5 秒觉得快速失败很好。但一次 Full GC、一次磁盘抖动、一次网络微突发就足够触发误判。我现在的默认值是10~15 秒跨机房部署会拉到 20 秒。代价是真实的宕机要这么久才能被感知到但比起频繁误判导致的临时节点抖动这个代价完全值得。第三临时节点不是进程挂了就删是会话失效就删。如果进程假死比如死锁只要它的心跳线程还活着临时节点就一直在。所以拿临时节点做存活探针是有前提的你的应用必须真的会响应而不是心跳线程独活。更稳的做法是配合业务层的健康检查双保险。注意不要在ConnectionStateListener里做耗时操作。这个回调是在 ZooKeeper 的事件线程里执行的阻塞它会直接拖垮心跳进而引发会话过期——一个非常讽刺的死循环。2.2 Watcher 是一次性的而且不保证不丢Watcher 是 ZooKeeper 提供变更通知的机制。你调用getData(path, true)或者getChildren(path, watcher)注册监听当节点的数据变了、被删了、子节点增删了服务端会推一个事件给客户端。关键点一一次性。一次注册只触发一次通知。收到通知后如果想继续监听必须重新注册。这个设计经常被吐槽但它的理由是合理的避免客户端处理不过来时事件堆积在服务端。代价就是你需要写注册—触发—再注册的循环而且在触发和再注册之间有一个窗口这期间的变更会丢。所以正确的用法是收到通知后先重新注册监听再去读取最新数据而不是反过来。关键点二事件可能丢。ZooKeeper 保证的是如果客户端收到了某个事件那么它看到的数据一定不早于该事件对应的状态。但它不保证客户端一定能收到事件。如果在服务端发出通知的瞬间连接断了这个通知就没了。所以完整的做法是Watcher 只作为有变化了的提示不能作为状态同步的唯一来源。定时全量拉取作为兜底是必须的。关键点三监听的是位置而不是内容。exists监听节点创建/删除/数据变更getData监听数据变更/删除getChildren监听子节点增删/父节点删除。注意getChildren不会监听子节点自身的数据变化。很多人在这里写错导致子节点配置改了却没触发刷新。关键点四羊群效应。如果 500 个客户端同时对同一个节点注册getChildren监听一次子节点变更会产生 500 个通知、500 次getChildren全量拉取瞬时把服务端打满。这就是经典的 Herd Effect。解法有两种一是改用 Curator 的PersistentWatcher/TreeCache它内部做了批量合并和本地缓存二是自己设计监听粒度把一个大节点下的所有子节点拆成多级路径或者干脆改成监听一个版本号节点客户端拉取增量。关键点五Watcher 在服务端是有内存成本的。每个注册的 Watcher 都要占服务端内存wchs、wchc、wchp这几个四字命令就是用来观察 Watcher 数量的。曾经有个案例某系统对十万个路径注册了监听服务端内存直接爆掉GC 时间飙升最后引发集群雪崩。任何超过万个 Watcher 的设计都该被 review。2.3 zxid一个 64 位数字撑起全局顺序zxid 是 ZooKeeper 事务 ID64 位整数拆成两段高 32 位是 epoch纪元/朝代低 32 位是自增计数器。每次 Leader 换届epoch 加 1低 32 位清零。这个设计解决了分布式系统里最麻烦的问题之一如何判断两个操作的先后尤其是在 Leader 变更之后。有了 zxidZooKeeper 能给出几个非常强的保证同一客户端的请求按发送顺序执行FIFO per session。客户端发的写请求带一个递增的 cxid服务端按序处理保证同一个客户端不会看到自己的操作乱序。所有写操作全局有序。所有写请求都路由到 LeaderLeader 分配 zxid 后广播所以任意两个写操作都有明确的先后。线性一致的写顺序一致的读。写是强一致的过半确认后才返回但读可能读到旧数据因为读请求可以由任意 Follower 处理而 Follower 的状态可能落后于 Leader。最后这一条是最高频的误解来源。很多人以为 ZooKeeper 是强一致的于是写出这样的逻辑A 客户端setData写了新值然后立刻让 B 客户端去getData期望读到新值。这在跨客户端场景下不成立。如果你真的需要读到最新值调用sync(path)再读——sync会强制当前连接的 Follower 追平到 Leader 的最新状态。但注意sync只保证在这个 Follower 上sync 之前的所有写都可见它本身也有开销不能滥用。我个人的实践原则是凡是写完立刻读、且要求读到新值的场景要么走sync要么把读请求也发到 Leader牺牲扩展性要么在业务层设计成自己写、自己读因为同一会话的 FIFO 保证能读到自己的写。第三种最优因为它不引入额外开销但要求你把读写绑定在同一个客户端实例上。3. ZAB 协议集群怎么保持一条心ZAB 全称 ZooKeeper Atomic Broadcast是 ZooKeeper 自己的一套一致性协议。它跟 Paxos/Raft 思路相近但细节不同最大的特点是为主备复制 崩溃恢复这个特定场景做了定制。你不需要能推导它但需要理解它的两个阶段和几个关键约束因为这直接决定了集群规模和部署形态的选择。3.1 三种角色两种模式集群里的节点分三种角色Leader唯一负责处理所有写请求、发起投票、广播提案。Follower参与投票包括选主投票和提案投票处理读请求。Observer不参与任何投票只同步数据、处理读请求。它的存在是为了提升读吞吐和跨机房读能力而不增加写延迟因为投票节点数没变。任意时刻集群要么处于崩溃恢复模式选主中不处理请求要么处于消息广播模式正常工作。切换过程对外表现为客户端短时间收不到响应甚至连接断开这是正常的但如果反复切换就说明集群有问题。关于节点数量有一条必须记住的规则投票节点Leader Follower必须是奇数且至少 3 个。原因是过半机制写操作需要超过半数节点确认。3 节点容忍 1 台挂5 节点容忍 2 台7 节点容忍 3 台。为什么不用偶数因为 4 节点的容错能力和 3 节点一样都是挂 1 台但多一台的开销纯浪费。还有一个容易被忽略的点节点越多写延迟越高。因为 Leader 要等过半节点落盘确认。3 节点等 2 个含自己5 节点等 3 个。跨机房部署时这个延迟会非常明显所以常见的做法是3 个投票节点放在同机房保证写性能再在异地加 2 个 Observer 提供本地读。3.2 选主过程谁 zxid 大谁说了算选主的触发条件是集群启动、Leader 崩溃、Leader 与过半节点失去联系。流程大致分几步每个节点先进入 LOOKING 状态投票给自己投出的票包含(myid, zxid, epoch)。收到别人的票后按规则 PK先比 epoch大的赢epoch 相同比 zxid大的赢zxid 也相同比 myid大的赢。这个优先级的设计意图很明确——必须选出数据最新的那个节点当 Leader否则会丢数据。如果某一轮中某个节点获得了过半票数它就当选 Leader。新 Leader 会把 epoch 加 1然后进入恢复阶段。其他节点如果发现自己数据落后于新 Leader就同步数据进入 FOLLOWING 状态。这里的关键洞察是选主优先保证数据完整性而不是速度。一个落后的节点即使先发起投票也当不上 Leader因为它的 zxid 小。这保证了已经提交的事务不会丢。实际排查中最常遇到的选主问题是反复选主俗称脑裂的前兆日志里能看到LOOKING、FOLLOWING、LEADING状态反复跳变。原因通常是节点间网络不稳定心跳超时syncLimit * tickTime频繁触发。机器负载太高tickTime到了但节点处理不过来。myid冲突——两台机器的 myid 文件写了同一个数字这个错误极其低级但真的会发生。数据目录磁盘满或者 IO 卡死导致事务日志写不进去节点自己退出投票。对应的调优手段把tickTime从默认 2000 适当调大比如 4000syncLimit从 5 调到 10给慢节点更多宽容但不要无脑调大因为这会延长故障检测时间。我一般的建议是tickTime2000, initLimit10, syncLimit5作为起点观察mntr里的zk_avg_latency、zk_max_latency、zk_outstanding_requests再决定要不要调。3.3 广播与恢复两阶段提交的变体正常工作时写请求走的是提案—确认—提交三步Leader 收到写请求转换成事务提案proposal分配一个 zxid先把提案写进自己的事务日志这一步很关键落盘了才算数。Leader 把提案广播给所有 Follower。Follower 收到后写入本地事务日志回 ACK。Leader 收到过半 ACK含自己就给这个提案打上已提交标记然后通知所有 Follower 提交同时把结果返回客户端。注意第 1 步和第 4 步的顺序先落盘再广播过半确认后才提交。如果 Leader 在广播后、提交前崩溃新 Leader 上任后需要判断这个提案是否该保留。判断依据就是新 Leader 一定是 zxid 最大的节点它本地日志里有的、且是已提交的提案必须保留未提交的提案如果它自己也没有就丢弃。这就是 ZAB 保证已提交不丢、未提交不重的核心逻辑。恢复阶段还有个细节叫数据同步新 Leader 会跟每个 Follower 比对 zxid决定是 DIFF增量同步、SNAP全量快照同步还是 TRUNC回滚多余的部分。日志里如果看到大量 SNAP说明有节点落后太多可能是该节点长时间离线或磁盘 IO 严重不足需要关注。关于ZooKeeper 3.5 之后的多线程处理还有个实践要点从 3.5 开始引入了多线程提交处理器允许把写事务的提交和读请求处理并行化读吞吐有明显提升。如果你还在用 3.4 系列升级到 3.8/3.9 是值得的但要注意 3.5 默认开启了四字命令白名单4lw.commands.whitelist升级后echo stat | nc会没反应需要显式配置这个坑很多人升级当天就踩了。4. 实操从零搭一套三节点集群并验证行为光讲原理没用这套东西必须自己动手跑一遍把创建临时节点、杀掉会话、看节点消失这个链路走通你才会对会话机制有肌肉记忆。下面是我常用的搭建流程环境是 LinuxJava 17zookeeper 3.8.x。4.1 配置与启动三台机器或一台机器的三个目录模拟每台一个zoo.cfgtickTime2000 initLimit10 syncLimit5 dataDir/data/zk/data dataLogDir/data/zk/logs clientPort2181 # 关闭四字命令白名单限制仅内网测试环境这么干生产要收紧 4lw.commands.whitelist* # 自动清理快照和事务日志 autopurge.snapRetainCount5 autopurge.purgeInterval12 # 限制单客户端连接数防止连接泄露打满 maxClientCnxns200 server.110.0.0.1:2888:3888 server.210.0.0.2:2888:3888 server.310.0.0.3:2888:3888几个参数的解释别照抄不思考dataDir和dataLogDir一定要分盘。事务日志是同步写fsync快照是异步写混在一块盘上快照生成时的 IO 抖动会直接拖慢写延迟进而引发一连串超时。这是我最强调的一条部署建议比任何 JVM 参数都重要。2888是节点间数据同步端口3888是选主投票端口。防火墙要放通这两个。autopurge.purgeInterval单位是小时默认 0 表示不清理生产必开否则磁盘迟早被快照撑满。我见过一次磁盘打满导致整个集群无法写入业务全线报错根因就是没配自动清理。maxClientCnxns默认只有 60稍微有点规模的客户端池就会撞上表现为连接被拒绝。调到 200~500 比较常见但要结合文件描述符上限一起调。然后每个节点的dataDir/myid文件写自己的编号内容就是1或2或3不要带换行、不要带空格。这个小文件出问题的概率意外地高用xxd确认一下比较稳。启动后验证# 看角色会返回 Mode: leader 或 Mode: follower echo srvr | nc 10.0.0.1 2181 # 看健康状态返回 imok echo ruok | nc 10.0.0.1 2181 # 看关键指标 echo mntr | nc 10.0.0.1 2181mntr输出里我重点关注这几个指标含义健康参考zk_avg_latency平均请求延迟ms个位数到十几持续上涨要查zk_max_latency最大延迟ms偶发尖峰正常持续高位异常zk_outstanding_requests排队请求数长期大于 10 说明处理不过来zk_znode_count节点总数突然暴涨通常是临时节点泄漏zk_watch_countWatcher 总数上万要警惕zk_ephemerals_count临时节点数结合实例数核对多了就是泄漏zk_pending_syncs等待同步的 Follower 数大于 0 说明有节点落后4.2 命令行现场记录验证临时节点与会话这套验证我建议每个接手 ZooKeeper 的人都做一遍# 连接 bin/zkCli.sh -server 10.0.0.1:2181 # 建一个持久节点 create /demo hello # 输出Created /demo # 建一个临时节点注意 -e create -e /demo/alive instance-1 # 输出Created /demo/alive # 建顺序节点看看序号长什么样 create -s /demo/task t1 create -s /demo/task t2 # 输出Created /demo/task0000000001、/demo/task0000000002 # 看 stat注意 ephemeralOwner 不为 0 的就是临时节点 stat /demo/alivestat /demo/alive会输出类似ephemeralOwner 0x18a3f2c9e4b0001的内容这个十六进制就是当前会话 ID。这是排查临时节点为什么没消失最快的入口拿到这个值去cons命令的输出里找对应会话还在不在。然后是关键的实验开第二个客户端删掉第一个客户端的会话。在第一个客户端里按CtrlC退出然后再连上去看ls /demo # 会发现 alive 没了只剩 task0000000001、task0000000002如果你把第一个客户端的进程kill -9而不是正常退出节点不会立刻消失要等到sessionTimeout到期。这个时间差就是很多服务下线了但注册中心还有残留问题的来源。所以正常关闭时应该主动删临时节点别指望超时回收。顺便试一下 Watcher# 客户端 A ls -w /demo # 客户端 B create /demo/newnode x # 客户端 A 会立刻打印 NodeChildrenChanged注意 A 只收到一次通知再改就没了必须重新ls -w。这就是一次性的直观体验。4.3 客户端实操用 Curator 而不是原生 API原生的ZooKeeper类能用但你需要自己处理重连、会话过期、Watcher 重注册、重试策略代码量会失控。生产环境我强烈建议用 Curator它把这些脏活都封装了。连接与重试RetryPolicy retryPolicy new ExponentialBackoffRetry(1000, 3, 10000); CuratorFramework client CuratorFrameworkFactory.builder() .connectString(10.0.0.1:2181,10.0.0.2:2181,10.0.0.3:2181) .sessionTimeoutMs(15000) .connectionTimeoutMs(10000) .retryPolicy(retryPolicy) .namespace(myapp) // 所有路径自动加 /myapp 前缀强烈建议 .build(); client.start(); client.blockUntilConnected(10, TimeUnit.SECONDS);namespace这个特性值得单说它让同一个集群可以被多个业务共用而路径不打架而且迁移时改一个前缀就行。我见过多个团队共用一个 ZooKeeper 集群结果路径冲突互相踩最后靠 namespace 解决的。ExponentialBackoffRetry(1000, 3, 10000)的意思是首次等 1 秒最多重试 3 次单次最长等 10 秒指数退避。注意 Curator 的重试只针对可重试的异常连接丢失、超时NodeExistsException这类业务异常不会重试。分布式锁InterProcessMutex lock new InterProcessMutex(client, /locks/order-123); try { if (lock.acquire(5, TimeUnit.SECONDS)) { // 临界区 } } finally { if (lock.isAcquiredInThisProcess()) { lock.release(); } }Curator 的InterProcessMutex就是标准的临时顺序节点 监听前一个节点实现天然避免羊群效应。推荐直接用不要自己写。自己写最常见的问题是忘了判断自己是不是序号最小的那个或者监听错了节点监听了父节点导致全员唤醒。配置中心TreeCache cache TreeCache.newBuilder(client, /config).build(); cache.getListenable().addListener((c, event) - { if (event.getData() ! null) { String path event.getData().getPath(); byte[] data event.getData().getData(); configMap.put(path, new String(data, StandardCharsets.UTF_8)); } }); cache.start();TreeCache会一次性把整个子树缓存到本地并持续监听所有节点的增删改查。相比自己注册一堆 Watcher它省心太多。但它会持有全量子树的内存节点数不能太大几万个节点以内没问题。选主LeaderLatch latch new LeaderLatch(client, /election/master, instanceId); latch.start(); latch.await(30, TimeUnit.SECONDS); // 等待成为 Leader if (latch.hasLeadership()) { // 只有 Leader 执行 }LeaderLatch的特点是一旦抢到就死死占住直到自己放弃或会话失效不主动让位。如果需要轮流坐庄用LeaderSelector配合autoRequeue()。5. 场景选型哪些活该接哪些活千万别接ZooKeeper 的能力边界很清楚但每年都能看到有人拿它干超出能力范围的事。这一节我把常见场景的取舍讲透帮你建立判断标准。5.1 配置中心能用但要加本地缓存和兜底配置中心是 ZooKeeper 最经典的用法之一把配置写成 znode客户端注册监听变更时推送。这套方案在配置项少、变更频率低的场景下非常好用实现简单一致性有保障。但必须配两个东西否则会出事一是本地文件缓存。客户端启动时先把配置落盘ZooKeeper 不可用时读本地文件保证服务能起来。我见过不止一次ZooKeeper 集群维护所有依赖它的服务重启全部失败因为启动时连不上就直接抛异常退出了。配置中心的可用性要求实际上比业务本身还高。二是兜底默认值。代码里写的默认配置要能保证基本可用不能全靠远程。另外配置节点的组织方式有讲究。不要把所有配置塞进一个节点1MB 上限和写放大问题也不要每个配置项一个节点节点数爆炸。我一般的做法是按模块分组每个模块一个节点内容用 JSON/YAML 序列化控制在几 KB。5.2 分布式锁三种实现对比锁是 ZooKeeper 用得最多的场景也是踩坑最多的。先看对比实现方式原理优点缺点抢占式同一路径 create -e谁创建成功谁拿锁实现最简单惊群严重、非公平、失败要轮询临时顺序节点 监听前驱序号最小的持有其他监听前一个公平、无惊群实现稍复杂Curator InterProcessMutex上面那种的成熟封装可直接用、支持可重入引入依赖抢占式的问题100 个客户端同时create99 个失败然后要轮询重试一轮轮打服务端压力巨大。而且不保证公平可能导致某些客户端一直抢不到饥饿。这个实现只有在竞争极少的场景比如一天几次的定时任务互斥才勉强能用。临时顺序节点方案的正确姿势每个客户端创建/lock/xxx-顺序节点然后getChildren拿到全部子节点排序如果自己是最小的就拿锁否则对自己前面那个节点注册exists监听。前驱节点被删了就重新检查自己是不是最小的。这样一次释放只唤醒一个客户端没有惊群。有一个致命细节必须在拿到锁之前判断锁是否已经被释放不能只依赖 Watcher。因为存在这个时序你getChildren之后、注册 Watcher 之前前驱节点被删了通知就丢了你会永远等下去。Curator 已经处理了这个问题它在循环里重新检查自己写一定要用先注册监听再检查状态的顺序并且每次唤醒后都重新完整走一遍判断逻辑。锁的另一个坑是锁超时和会话超时的关系。如果你给锁设了 5 秒超时但会话超时是 15 秒那么锁超时释放时节点还在别的客户端以为锁还被占着。Curator 的acquire(timeout)在超时后会尝试撤销创建的节点但撤销本身可能失败。我的建议是锁的超时时间要么不设靠会话超时兜底要么设得远小于会话超时并且确保撤销逻辑可靠。还有一点ZooKeeper 锁不能防止持锁进程假死。如果进程拿到了锁但卡死了比如死循环、Full GC 卡了 20 秒锁会一直持有到会话超时。这期间业务是停摆的。所以关键路径上锁必须配合持锁方的活性检测——比如在锁节点里写入持锁时间其他方定期检查是否超时。5.3 服务注册与选主能用但要注意规模服务注册的原理很简单每个实例启动时创建临时节点比如/services/order/instance-0000000001下线时删除宕机靠会话超时清理。消费方监听父节点获取全量列表。问题出在规模上。当实例数到几千、并且每个实例的心跳会话都要维护的时候ZooKeeper 的内存和连接压力会明显上升。更麻烦的是下线事件的延迟会话超时要 10~15 秒这期间调用方还在往死实例发请求。虽然可以通过客户端负载均衡的重试和熔断缓解但体验不如基于长连接主动下线的方案。我的经验判据是实例总数在 1000 以内ZooKeeper 做注册中心完全没问题超过 3000 并且需要秒级感知就该考虑专门的服务发现组件了。如果必须用做两件事一是把临时节点的路径按业务分片减少单父节点的子节点数二是消费方加定时全量拉取兜底不要只依赖 Watcher。选主Leader Election反而是 ZooKeeper 最合适的场景之一因为参与选主的通常只有几个到几十个节点压力极小。LeaderLatch就够用。要注意的是选主之后的脑裂问题老 Leader 可能因为网络分区以为自己还是 Leader。标准的防护是围栏fencingLeader 每次操作前检查自己持有的 znode 是否还在或者带上一个单调递增的 epoch 号下游拒绝旧 epoch 的请求。这一步不能省否则数据会被两个 Leader 同时写坏。5.4 它不适合做什么列几条明确的反面清单看到这些需求就应该换方案存业务数据/大文件。单节点 1MB 上限写放大严重快照大。用对象存储或数据库。当消息队列。Watcher 是一次性的、可能丢的不适合做可靠消息投递。而且消息积压会撑爆内存。用专门的消息队列。高频写。所有写都过 Leader 并且要 fsync写 QPS 有硬天花板。计数、秒杀库存这类场景用 Redis 或数据库。海量节点。几十万节点会让快照生成变慢、内存占用升高、启动同步时间变长。我的经验上限是单集群十万以内超过就该拆。强一致读。读可能读到旧值需要sync才能保证而sync有开销。需要强一致读的场景要用别的方案。跨地域低延迟写。跨机房投票的 RTT 直接叠加到写延迟上。跨地域只用 Observer 做本地读。6. 排查实录几类高频故障的定位路径下面这些是我实际处理过的、或者帮别人定位过的典型问题。我把现象、根因、排查手段和解决方式整理成可直接对照的形式。6.1 会话频繁过期先看 JVM再看网络现象日志里频繁出现Session expired event服务注册的临时节点反复消失又出现调用方报No available instance。排查顺序看应用侧 GC 日志。Full GC 停顿超过会话超时时间的 1/3就极易触发误判。一个 8 秒的 Full GC 配合 10 秒的会话超时基本必过期。看 ZooKeeper 服务端的mntr特别是zk_max_latency。如果服务端处理一个请求要几百毫秒客户端心跳也会排队同样会过期。抓包看心跳间隔是否规律。如果不规律可能是客户端事件线程被业务代码阻塞了——在 Watcher 回调里做耗时操作是头号嫌疑。检查网络是否有周期性抖动比如某些中间设备定时清理连接表。解决手段会话超时从 10 秒提到 15~20 秒把 Watcher 回调里的逻辑全部丢到独立线程池GC 参数调优尤其是堆大小和 G1 的MaxGCPauseMillis如果服务端延迟高检查磁盘 IO 和dataLogDir是否和dataDir分离。提醒不要用调大超时掩盖所有问题。如果每次故障都是同一台机器的会话过期那大概率是那台机器的网络或负载问题调参数只是拖延。6.2 集群起不来 / 反复选主从 myid 和日志入手现象三个节点启动后只有两个能组成集群或者日志里LOOKING反复出现。排查清单检查项方法常见错误myid 是否唯一cat $dataDir/myid两台写了同一个数字myid 格式xxd $dataDir/myid带了换行符或空格server.x 配置是否一致三台机器的 zoo.cfg 对比端口写错、IP 写成本机回环端口连通性telnet ip 2888/3888防火墙只开了 2181事务日志是否可写ls -l $dataLogDir磁盘满、权限错时间是否同步date对比时钟漂移过大影响超时判断是否有残留的 version-2 数据ls $dataDir/version-2换过集群但旧数据没清导致 epoch 冲突那个旧数据没清的坑特别隐蔽曾经有个环境重建集群只改了配置没清数据目录新集群启动时发现本地 epoch 比别人的大强行当选 Leader然后跟其他节点同步失败整个集群起不来。重建集群前务必备份并清空所有节点的 dataDir 和 dataLogDir。6.3 节点数暴涨与磁盘打满两个慢性病节点数暴涨通常意味着临时节点泄漏。zk_ephemerals_count持续上涨而实例数没变基本可以确定是某些客户端会话没正常关闭或者代码里创建了临时节点但忘了在关闭时删除。用cons命令可以列出所有连接和它们的临时节点数配合ephemeralOwner字段能定位到具体会话。磁盘打满的元凶几乎总是快照和事务日志没清理。除了配autopurge还要注意快照大小和节点数、单节点数据量正相关。如果单个快照到了几百 MB说明数据模型设计有问题该拆分或迁移了。另外提一个容易忽略的dataLogDir所在磁盘的 IOPS 是写入性能的瓶颈。用机械盘跑 ZooKeeper 写操作延迟能到几十毫秒直接拖垮整个集群。SSD 是标配条件允许的话把事务日志单独放一块 SSD。6.4 常见问题速查表现象可能原因快速验证处理客户端连不上报 ConnectionLoss服务端不可达/防火墙/端口错echo ruok | nc ip 2181检查网络和端口连接被拒 ConnectionRefusedmaxClientCnxns超限cons看连接数调大限制、排查连接泄漏写入超时磁盘 IO 慢 / 过半节点不可用mntr看 latency、srvr看 Mode分离日志盘、恢复节点临时节点不消失会话还活着进程假死stat看 ephemeralOwnercons找会话杀掉僵尸进程或等超时Watcher 不触发一次性已用过 / 事件已丢检查代码是否重新注册改用 TreeCache/PersistentWatcher读取到旧数据读走了落后的 Follower对比各节点mntr的 zxid用sync或改读 Leader四字命令无响应3.5 白名单未配置看 zoo.cfg配4lw.commands.whitelist集群无法写入剩余节点不足半数srvr看 Mode恢复节点检查是否脑裂NodeExistsException频繁并发创建同一路径看是否有重试逻辑漏判改用顺序节点或用creatingParentsIfNeeded7. 一些踩过坑之后固化下来的习惯写到这里我想分享几个纯粹来自实践、不太会在文档里出现的习惯都是我这些年撞了墙之后固化下来的。第一所有路径都带版本前缀。比如/app/v1/config而不是/app/config。这样当数据模型要改结构时可以新建v2并行运行客户端灰度切换出问题回滚只改个前缀。这个习惯救过我一次配置结构改版上线后发现新格式客户端解析失败因为路径分开了回滚只需要改一个常量不用回滚代码。第二节点数据和业务代码解耦。不要往 znode 里塞 Java 序列化的对象ObjectOutputStream那套。用 JSON 或者纯文本键值对这样其他语言的客户端、命令行、监控脚本都能读。我见过一个系统把 Java 对象序列化进 znode结果运维想看一眼配置内容都做不到排查问题极其痛苦。第三所有 ZooKeeper 操作都包一层超时。包括getData、create、exists一律带超时。底层连接出问题时无超时的调用会挂在那里把业务线程池耗光。Curator 的重试策略不解决这个问题它只控制重试次数不控制单次调用时长。第四写一个能一键导出全量树的小工具。出故障时能快速dump出整棵树的结构和 stat比一条条命令敲快一百倍。我自己写过一个基于 CuratorTreeCache的小程序输入路径就递归打印所有节点的路径、数据摘要、版本号、ephemeralOwner定位问题时非常高效。第五监控至少盯四个指标。zk_avg_latency、zk_outstanding_requests、zk_znode_count、zk_ephemerals_count。前两个看性能后两个看数据规模异常。这四个指标加上集群角色状态能覆盖八成以上的故障前兆。告警阈值我一般设成平均延迟 20ms 持续 5 分钟、排队请求 20、dnnode 数量 1 小时内增长超过 50%。第六压测一定要做但别用真实的 ZooKeeper 集群做。用单机三实例模拟重点压两件事写操作在集群降级挂一台后的延迟变化以及大量临时节点创建删除时的 GC 表现。我做过一次压测2000 QPS 的临时节点创建某个节点 GC 时间到了 3 秒直接引发了另一次会话过期链式反应非常快。这种表现只有压测才能看到。最后一点心得ZooKeeper 这套东西用对了是隐形的基石用错了是持续发作的慢性病。判断用没用对有个很简单的标准——你的系统里ZooKeeper 挂了之后会发生什么。如果答案是大面积不可用那说明你把太多关键逻辑压在它身上了需要加缓存、加降级、加兜底。如果答案是短暂的功能降级核心链路不受影响那才是健康的用法。我自己维护过的最稳的一套系统ZooKeeper 的定位就是元数据的权威来源所有读都走本地缓存写只在少数管理操作时发生ZooKeeper 维护期间业务几乎无感——这才是协调服务该有的样子。