尧图网站建设 
老话讲“见过猪跑和吃过猪肉是两码事”ZooKeeper 在我这儿就属于“吃了好几年猪肉”的项目。前后在好几个生产环境里和它打交道从最初 Hadoop 集群里陪跑的协调角色到后面自己上手维护、排查脑裂、调 JVM 参数算是把这只“动物园管理员”的脾气摸了个七七八八。这个项目标题叫“ZooKeeper 知多少”我看很多刚入门的朋友对它又爱又怕——爱是因为几乎所有分布式中间件都绕不开它怕是因为它概念多、术语杂什么 ZNode、Watch、ZAB、会话超时听着像天书。这篇就把我知道的、踩过的、调优过的 ZK 经验一次说清楚它到底解决什么问题、核心机制怎么理解、生产环境怎么部署和运维、怎么和 Hadoop 生态整合实战以及那些文档里不会明说的坑。不管你手里是三个节点的开发环境还是上百台机器的生产集群这篇都能给你点实在的东西。1. 先弄明白 ZooKeeper 到底在解决什么问题很多人第一反应是“ZooKeeper 是不是个注册中心”这么说对了一半。它在某些场景下确实能当注册中心用但它的定位远比注册中心要底层。我习惯把它理解成分布式系统里的分布式协调内核。你可以把 ZK 看成一支分布在各台机器上的“小军队”它们通过一套严格协议保证彼此状态永远一致对外提供一套极简的文件系统接口让上层的各种分布式组件用它来达成共识、感知变化、选举主节点。1.1 为什么分布式系统离不开“协调”这件事单机系统里没有协调问题因为就一份数据、一个进程不存在“谁说了算”的分歧。分布式系统一上来问题就全冒出来了。比如说你有 5 台机器共同提供一个服务其中一台挂了剩下 4 台怎么知道要接手它的活再比如多个客户端同时要改一份配置怎么保证大家看到的版本是一致的更麻烦的是网络分区——左边两台机器和右边三台机器暂时联系不上两边都想干活这时候听谁的这些问题本质都是“分布式共识”问题。ZooKeeper 的厉害之处在于它把这种共识能力做成了一个通用的基础设施让上层的 HBase、Kafka、Hadoop 这些系统不用各自发明轮子直接往 ZK 里写几个节点、监听几个事件就能实现主节点选举、集群成员管理、分布式锁、配置下发。它提供的不是一个完整的解决方案而是解决问题的“原语”这句话我建议所有初学者刻在脑子里。1.2 ZooKeeper 在生态里的位置和典型使用场景我见过最经典的比喻是把 ZK 比作“分布式系统的神经系统”。Kafka 用 ZK 保存 broker 列表、选举 controllerHBase 用 ZK 做 HMaster 的选举和 meta 表的定位Hadoop HDFS 用 ZK 做 NameNode 的自动故障转移Dubbo、Curator 这些框架也拿它做服务注册与发现。哪怕是云原生时代Etcd 在功能上也是同类产物很多老系统迁移之前还是离不开 ZK。我整理了几个最常见的实际场景你在理解各个中间件源码时都会碰到场景具体用法依赖的 ZK 特性Leader 选举多个节点竞争创建同一个临时节点谁创建成功谁是主临时节点 节点唯一性服务注册与发现每个服务在指定路径下创建临时顺序节点客户端监听父节点临时节点 Watch 通知分布式锁多个客户端在锁路径下创建临时顺序节点取序号最小者获锁临时顺序节点 Watch配置管理把配置写到 ZNode 上客户端监听变化并动态更新Watch 机制 持久节点集群元数据存储HBase meta 表地址、Kafka broker 列表等持久节点 顺序节点这里要注意一个原则ZK 不适合存大量业务数据。它的设计目标是存储少量的协调状态比如几 KB 的配置、几个字节的选举标记。谁要是脑洞大开往里面写几百 MB 的数据那是把 ZooKeeper 当数据库使了生产环境分分钟教你做人。我后面会专门说这个坑。2. 五句话讲透 ZK 的核心机制别再被概念绕晕学习 ZK 最大的障碍是一堆术语扑面而来ZNode、Watch、Session、Quorum、ZAB、ACL每个单词都认识放在一起就晕。我的经验是不要一开始扎进源码而是先抓住三个核心机制数据模型ZNode、监听机制Watch、一致性协议ZAB。这三件事弄明白了整个 ZK 的骨架就搭起来了。2.1 ZNode既像文件路径又比文件多了一堆脾气ZK 的命名空间看起来极像一个文件系统. /开头一层一层往下挂。比如/hbase/meta-region-server就是 HBase 用来存 meta 表地址的节点。但 ZNode 和普通文件有本质区别节点是分类型的。持久节点Persistent写进去就一直在除非主动删除临时节点Ephemeral和客户端会话绑定客户端会话一断节点自动消失顺序节点Sequential会在你指定的路径后面自动追加一个单调递增的序号比如lock_0000000001。这几种节点组合起来就能玩出选举、锁、注册发现这些花样。节点是有版本号的。每个 ZNode 维护version、cversion、aversion三个版本号对应数据变更次数、子节点变更次数、ACL 变更次数。这让乐观锁式的并发控制成为可能后面讲分布式锁时大家会看到它的威力。节点不能有“部分写入”。要么整个节点数据一次写成功要么不动不存在写了一半的状态。这个特性对上层应用太重要了。我初学的时候老记不住临时节点后来找了个生活化的类比临时节点就是网吧里的上网记录你刷卡上机创建会话记录就产生你下机走人断开会话记录自动注销不需要管理员手动删。这个类比帮我记了好多年。2.2 Watch 机制一次性订阅别指望“推送”ZK 的 Watch 机制让客户端能感知节点变化。客户端可以对某个节点注册 Watch当这个节点数据变化、子节点增减、节点删除时ZK 会向客户端发送一个通知。但这里有两个非常关键的细节新手必踩Watch 是一次性的。触发一次之后这个监听就失效了想继续监听必须重新注册。所以客户端处理完事件后的第一件事就是再注册一次 Watch这个套路我当年忘了写结果线上动态配置只更新了一次后面全不生效。Watch 通知只告诉“你关心的节点发生变化了”不会告诉你变化后的具体数据。收到通知后客户端必须主动再调一次 getData 去拿最新值。还有个容易忽略的点Watch 的触发顺序是异步的但不保证“先到先得”。它只保证“最终你会收到一个通知”而且如果客户端和服务器之间连接断开期间发生的变化在重连后可能不会重新通知——这也是各种 Curator 框架要封装重注册逻辑的原因。2.3 ZAB 协议与 Leader 选举那个让集群“自动分出老大”的机制ZK 集群通常由奇数台机器组成比如 3 台、5 台、7 台。之所以要求奇数是因为它采用了“多数派”决策模型一个写请求只有获得了超过半数节点的确认才算真正提交成功。3 台允许挂 1 台5 台允许挂 2 台。过半机制也决定了 ZK 集群的最小规模是 3 台2 台毫无意义因为挂 1 台就达不到多数派。整个 ZK 的一致性由 ZAB 协议保证它有两个阶段崩溃恢复Leader 选举集群启动或 Leader 挂了时所有节点通过投票选出新的 Leader选出来的 Leader 必须拥有最新的数据。原子广播数据同步Leader 接收写请求把事务广播给所有 Follower超过半数确认后提交。我对 ZAB 的理解是它把“选老大”和“听老大的”这两个过程拆得很干净。选 Leader 用的是 Fast Leader Election 算法实际开发中不用关心太多细节但运维排查时有一个概念必须懂ZXID事务 ID。每个事务都有唯一的递增 ID其中包含了 Leader 的任期信息。选举时 ZK 会比较 ZXID谁的日志最新谁优先当 Leader这样就保证了不会出现新 Leader 数据比旧 Leader 还旧的情况。有朋友会问既然有 Leader客户端读写还是要通过它吗读写走的是另一套逻辑所有节点的写请求都会转发到 Leader而读请求可以由任意节点直接响应。这也是 ZK 的一个经典性能取舍——它天生是“读可扩展、写不扩展”的架构。想靠加机器提升写性能是不可能的写性能由 Leader 和多数派确认的延迟决定但读能力是可以横向加的。2.4 会话Session与超时配置这是一个值得被反复强调的点客户端与 ZK 建立连接后会维护一个会话。会话有两个关键参数sessionTimeout会话超时时间和sessionId会话标识。ZK 通过心跳维持会话默认客户端会以不超过超时时间三分之一的间隔向服务器发送心跳。如果你配置的会话超时太短网络抖动一下就会导致会话过期太长则临时节点删除会变得滞后。实际生产中我一般建议把sessionTimeout设在 10 到 30 秒之间。太短了网络 GC 就能让你“掉线”太长了故障切换时间会拉得很长。HBase、Kafka 各自封装客户端时都有自己默认的超时配置比如 Kafka 老版本默认 6 秒生产环境经常出现“明明 ZK 没挂但 Kafka 报 ZK 超时”的情况十有八九是会话超时配置不够合理而不是 ZK 真挂了。3. 从零搭建一个生产可用的 ZooKeeper 集群纸上谈兵聊完概念接下来聊聊动手。我用一台测试机的简化配置来演示不过生产环境部署完整 3 节点集群的步骤几乎一模一样只有节点数、IP、内存和磁盘的差异。3.1 部署前要做的硬件评估和环境准备ZK 本身非常轻量是个 Java 进程内存占用通常在几百 MB 到 2GB 之间。但它有两个硬性指标常被忽视磁盘 IO 和文件描述符。ZK 的所有写操作先写事务日志TxnLog再定期生成快照Snapshot所以磁盘写入性能直接决定写延迟。我建议系统盘和数据盘分离事务日志目录和快照目录可以分盘放减少相互干扰。至少给 ZK 进程所在用户配置ulimit -n到 65535 以上否则大并发下会报 “Too many open files”。确认 JDK 版本ZK 3.5 以后要求 JDK 8 及以上3.8 之后 JDK 11 也是可用的。一定要避免在 JDK 版本上抠抠搜搜。环境上其实没太多要特别装的东西。官方压缩包解压即用不需要编译。做法是把apache-zookeeper-x.x.x-bin.tar.gz注意认准带-bin的那个包不带 bin 的是源码包下载到服务器解压到/opt/zookeeper然后软链一个不带版本号的路径方便以后升级。3.2 修改核心配置文件 zoo.cfg别忽略每个参数的含义从conf目录复制一份zoo_sample.cfg改成zoo.cfg然后改成下面这个样子tickTime2000 initLimit10 syncLimit5 dataDir/data/zookeeper/snapshot dataLogDir/data/zookeeper/txnlog clientPort2181 maxClientCnxns60 autopurge.snapRetainCount5 autopurge.purgeInterval12 server.1172.16.10.11:2888:3888 server.2172.16.10.12:2888:3888 server.3172.16.10.13:2888:3888几个参数是这么个逻辑tickTimeZK 的最小时间单位单位毫秒。心跳、超时、选举都基于它计算。initLimitFollower 启动后与 Leader 完成数据同步的最大时间单位是 tickTime 的倍数。集群数据量大、网络慢时这个值可以适当调大默认 10 个 tick。syncLimitFollower 与 Leader 之间心跳检测的超时倍数。如果网络经常抖动建议从 5 调到 10。否则 Follower 会被误判为“失联”然后反复进入选举。dataLogDir事务日志独立目录。这个配置决定写性能生产环境务必配置。autopurge.snapRetainCount和autopurge.purgeInterval控制自动清理旧快照和日志避免磁盘被日志撑爆。早期 ZK 不自带清理大家得写 cron 脚本3.4 之后自带自动清理建议打开。配置完后还要在dataDir指向的目录下创建myid文件内容是对应的 server 编号。比如第一台机器echo 1 /data/zookeeper/snapshot/myid。这个文件就像是每台机器的身份证很多新手第一次搭建 3 节点集群失败就是忘了写或者写错了 myid节点一直起不来。三个节点之间的端口也要说清楚2888是 Follower 和 Leader 之间同步数据的端口3888是选举投票端口。这两个端口在防火墙、安全组规则里一定要放通否则节点之间互相发现不了。之前帮朋友排查过一个问题2181 客户端端口通了但 3888 端口被安全组挡了结果集群永远选不出 Leader日志里全是连接拒绝。这个问题极其隐蔽大家一定提前检查。3.3 启动集群和验证健康状态别裸奔启动倒是简单每个节点执行bin/zkServer.sh start但我强烈不建议启动完看一眼“好像起来了”就收工。我会做下面这几步验证看进程状态bin/zkServer.sh status如果输出Mode: leader或Mode: follower说明角色已经选出来了。看端口监听netstat -tlnp | grep 2181。用四字命令ruok检查节点是否健康echo ruok | nc 127.0.0.1 2181如果返回imok说明节点状态正常。用echo stat | nc 127.0.0.1 2181查看角色、Zxid、客户端连接数等关键信息。这里要提醒一件事ZK 自带的 4 字命令ruok、stat、mntr、conf、cons 等默认是开启的但存在一定的安全风险。在公网环境下任何能连到 2181 端口的人都能执行这些命令查看集群状态甚至通过dump看到会话详情。生产环境建议在zoo.cfg中设置4lw.commands.whitelistruok,stat,mntr,conf来限定允许的命令集合同时用安全组或防火墙把 2181 端口限制在内网范围内。3.4 用 zkCli 快速熟悉 ZK 的基本操作命令行是理解 ZK 数据模型最好的老师。进入交互模式bin/zkCli.sh -server 127.0.0.1:2181几条常用指令ls / create /myapp hello get /myapp set /myapp hello2 create -e /tmp_node ephemeral # 临时节点 create -s /seq_node seq # 顺序节点 delete /myapp我建议新手亲手做两个实验实验一验证临时节点的生命周期。用create -e /tmp_node tmp创建一个临时节点然后按CtrlC退出会话再用另一个终端执行ls /你会发现/tmp_node已经消失了。这个实验能让你把“临时节点与会话绑定”的印象刻进脑子里。实验二观察顺序节点的序号。连续执行三次create -s /seq_node seq然后ls /你会看到/seq_node0000000001、/seq_node0000000002、/seq_node0000000003这样的节点。这就是后面分布式锁的基础。命令行还有一个非常实用的调试技巧用get时加上-w参数可以注册一个 Watch然后开另一个窗口set节点数据你会发现第一个窗口立刻收到WATCHER::WatchedEvent通知。这个实验能帮你理解“一次性触发”的含义——触发一次后再 set 就不再有通知了。4. Java 客户端实战自己动手实现一个分布式锁聊完命令行我猜你想知道“代码里到底怎么用”。ZK 官方提供的 Java API 比较底层Curator 框架封装了常用高级功能。但为了让你真正理解原理我先用原生 API 写一个简单的分布式锁再用 Curator 的现成方案做对比这样你既能看懂底层逻辑又能直接用于生产。4.1 原生 ZK API 实现分布式锁的核心逻辑分布式锁的思路其实非常清晰多个客户端要抢一把锁就让它们在同一个父节点下创建临时顺序节点ZooKeeper 保证这些节点的序号是全局唯一的递增的。然后每个客户端检查自己创建的节点是不是所有子节点里序号最小的如果是说明抢到了锁如果不是就监听序号比它小一号的那个节点等它删除后再尝试。这个算法又叫 “lock using ephemeral sequential node”业内用得非常多。代码骨架长这样public class ZkDistributedLock implements AutoCloseable { private final ZooKeeper zk; private final String lockRoot; private final String lockName; private String nodePath; public ZkDistributedLock(String connectString, String lockPath, String lockName) throws Exception { this.lockRoot lockPath; this.lockName lockName; // 连接是异步的这里用 CountDownLatch 等连接建立 CountDownLatch latch new CountDownLatch(1); this.zk new ZooKeeper(connectString, 30000, event - { if (event.getState() Watcher.Event.KeeperState.SyncConnected) { latch.countDown(); } }); latch.await(); // 确保父节点存在 if (zk.exists(lockRoot, false) null) { zk.create(lockRoot, new byte[0], ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT); } } public void lock() throws Exception { // 1. 创建临时顺序节点 nodePath zk.create(lockRoot / lockName -, new byte[0], ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL); // 2. 尝试获得锁 while (!tryAcquire()) { synchronized (this) { wait(); } } } private boolean tryAcquire() throws Exception { ListString children zk.getChildren(lockRoot, false); Collections.sort(children); // 找到自己 String currentNode nodePath.substring(nodePath.lastIndexOf(/) 1); int index children.indexOf(currentNode); // 序号最小获得锁 if (index 0) { return true; } // 监听前一个节点等它消失 String prevNode lockRoot / children.get(index - 1); zk.exists(prevNode, event - { if (event.getType() Watcher.Event.EventType.NodeDeleted) { synchronized (ZkDistributedLock.this) { ZkDistributedLock.this.notifyAll(); } } }); return false; } public void unlock() throws Exception { // 释放锁就是删除自己创建的节点 if (nodePath ! null) { zk.delete(nodePath, -1); } zk.close(); } Override public void close() throws Exception { unlock(); } }这里面有四个非常关键的设计点临时节点的意义防止死锁。拿到锁的客户端如果突然宕机ZK 的会话检测机制会自动删除临时节点锁自然释放后续节点立刻被唤醒。不需要复杂的“锁超时续期”逻辑。监听前一个节点而不是父节点避免惊群效应。如果所有客户端都监听父节点一个节点删除会唤醒所有等待者然后大家疯狂去抢锁大部分都会失败造成无谓的压力。只监听的“前一个节点”就保证同一时刻只有一个客户端会被唤醒这个设计在分布式锁里叫“公平锁”。序号的排序规则。ZooKeeper的顺序节点序号是 10 位数字的补零字符串所以字符串排序和数字排序是一致的。这也是 Files 里顺序节点可以比较的原因。finally 块里的清理动作。unlock一定要放在try-finally中就算业务代码抛异常也要释放锁否则锁被自己一直占着别人永远进不来。4.2 生产环境直接用 Curator不要再重复造轮子原生 API 写一遍是为了理解但生产环境我绝对不会直接用裸 API因为重连、会话恢复、Watch 重注册的细节太容易出错了。Curator 把这些全封装好了还提供了InterProcessMutex这样开箱即用的锁实现CuratorFramework client CuratorFrameworkFactory.builder() .connectString(172.16.10.11:2181,172.16.10.12:2181,172.16.10.13:2181) .sessionTimeoutMs(15000) .connectionTimeoutMs(5000) .retryPolicy(new ExponentialBackoffRetry(1000, 3)) .build(); client.start(); InterProcessMutex lock new InterProcessMutex(client, /locks/order-create); try { if (lock.acquire(5, TimeUnit.SECONDS)) { // 拿到了锁执行业务 } else { // 超时没拿到锁做降级处理 } } finally { lock.release(); } client.close();这里建立客户端时有个细节值得展开一下retryPolicy一定要配。Curator 默认的重试策略是ExponentialBackoffRetry第一次失败后等 1 秒重试第二次等 2 秒第三次等 4 秒。如果集群正在做 Leader 选举客户端暂时连不上没有重试策略的话业务代码直接抛异常。有重试策略就能平稳度过选举期。4.3 配置中心怎么做Watch 的正确使用姿势分布式锁是写路径的经典场景读路径的经典场景是配置中心。思路是把配置写到一个持久节点所有客户端启动时读一次并注册 Watch配置变更时收到通知再去读新值并更新本地缓存。但是这里的坑在于如果客户端与 ZK 的连接断开再重连期间发生的配置变更可能会丢失通知。简单的应对办法是在收到SyncConnected事件重连成功后主动重新读一次配置并重新注册 Watch。Curator 提供了一套NodeCache和PathChildrenCache它们内部实现了重连后的重新注册逻辑用起来非常省心NodeCache cache new NodeCache(client, /config/app1); cache.getListenable().addListener(() - { byte[] data cache.getCurrentData().getData(); // 更新本地配置 }); cache.start();我自己经历过一次事故某个数据平台依赖配置中心做实时开关某天网络抖动导致 ZK 会话重新建立但客户端 Watch 没重新注册线上开关状态一直停留在旧值业务数据多跑了一个多小时才发现。从那以后我定了一条规矩凡是直接使用原生 API 的地方必须处理重连接事件凡是能用 Curator 封装的绝不自己写 Watch 逻辑。5. Hadoop 整合实战HDFS 高可用里 ZK 到底扮演什么角色标题里带着“Hadoop 和 ZooKeeper 整合实战”这部分我就拿 HDFS 高可用HA来讲。很多同学搭过 HDFS HA但只知其然而不知其所以然。这里是 ZK 最典型、最能体现价值的整合场景。5.1 HDFS HA 的架构里ZK 管了哪三件事在 NameNode 高可用架构中两个 NameNode 一个 Active、一个 Standby正常情况下 Active 提供服务Standby 同步 EditLog 待命。当 Active 节点宕机时Standby 需要快速感知并升级为 Active。这个“感知、选举、切换”的过程如果没有一个外部的协调者很容易出现“双主”的脑裂——两个 NameNode 同时以为自己是 Active那整个集群就乱了。ZooKeeper 在这一整套流程中主要做三件事Active NameNode 会在 ZK 上创建一个临时节点/hdfs/ha/nameservice1/ActiveBreadCrumb这个节点的存在就是“我是 Active”的凭证。临时节点嘛节点死了就不存在了。ZKFCZK FailoverController监听这个节点。Active NameNode 崩溃后临时节点自动消失ZKFC 感知到变化。Standby NameNode 通过 ZK 进行选举竞争创建同一个临时节点谁创建成功谁成为新的 Active。这里脑裂防护有个关键机制Standby 成为 Active 之前会先尝试通过 SSH 登录到旧的 Active 上执行fuser -k强制杀掉旧进程fencing隔离再去 ZK 创建节点。即使 SSH 失败了ZK 里的临时节点也会在旧节点会话超时后自动消失形成双重保险。5.2 实际配置中容易踩的坑HDFS HA 整合 ZK 时需要先在 ZK 里初始化 HA 状态存储路径这一步常常被忽略hdfs zkfc -formatZK这个命令会在 ZK 中创建/hdfs/ha等相关节点。如果没初始化之后启动 ZKFC 时它会尝试创建节点但权限不对或路径冲突经常报org.apache.zookeeper.KeeperException$NodeExistsException。另一个坑是edits 共享目录。HA 下两个 NameNode 要共用一个 journals 目录这个和 ZK 没有直接关系但很多新手把这两件事混在一起明明 ZK 状态正常却因为 JournalNode 没配好搞了半天。一般来说在部署之前先分清楚ZK 负责的是活性探测和自动切换JournalNode 负责的是元数据日志共享两者职责完全不同不能混为一谈。生产环境配置了自动故障转移后还有一个非常实用的检查项定期用echo stat | nc zk_ip 2181看各节点的连接数是否均匀。如果有大量客户端连到一个节点说明连接配置里没有把 ZK 地址列表都填进去。ZK 客户端连接串里填多个地址时客户端会随机选择一个进行连接天然地起到负载均衡作用但如果只填一个 IP所有客户端就会集中打到一台机器上这台机器成为瓶颈另外两台却闲着。5.3 整合 Kafka 和 HBase一个模式练百遍肌肉记忆如果你理解了 HDFS HA 的整合套路Kafka 和 HBase 你会发现如出一辙。Kafka 老版本在 ZK 上注册 broker 信息/brokers/ids/0用 ZK 选 controller用 Watch 感知 broker 列表变化。HBase 用 ZK 选 HMaster同时把 meta 表地址写到/meta-region-server。它们都是同一个模式写节点表示状态、监听节点感知变化、竞争节点完成选举。你只要把这个模式吃透看哪个框架的 ZK 整合代码都是十行之内就能猜出大概。这也是我把 ZK 称作“中间件的中枢神经系统”的原因。哪个中间件想进集群一起工作第一步就是先到 ZK 里报个到、占个位置。理解了这一点再看 Kafka 的config/server.properties里zookeeper.connect配置你就能自动脑补出一整套“注册、心跳、选举、感知”的流程。6. 运维经验与故障排查实录全是文档里没有的细节这一节我认为是整篇价值最高的部分。ZK 真正的难点不在部署而在运行期。稳定运行一年半载不出事是常态一出事就是核心链路断裂。下面这些问题我全部在真实环境里碰到过给你一条条拆解排查思路。6.1 会话超时和连接断开不一定是 ZK 挂了“ZK 连接断了”是我遇到最多的一类误报。很多业务报警“ZooKeeper session expired”第一反应是去查 ZK 集群状态但 ZK 三台机器明明都活着角色也正常。这时候真正的问题往往在客户端客户端机器负载高导致 GC 停顿心跳发不出去会话被服务器判定超时。Kafka 里线程“卡死”是典型场景某个消费线程里堵塞了五分钟做重 IOZK 会话过期导致这个 broker 临时节点被删除集群认为该 broker 下线了分区被重新分配。处理完业务线程Broker 重新注册又触发一轮 rebalance。这种“GC 停顿 会话超时 临时节点消失 上游感知重分配”的连锁反应是大数据集群里最常见的慢故障触发器。排查思路大概是先看客户端日志里Session expired前后有没有Full GC的线索比如jstat -gcutil观察老年代增长。再调整sessionTimeout不要墨守默认值。Kafka 里可以调zookeeper.session.timeout.ms适当调大能显著降低误判概率。关注客户端所在机器的 CPU 和 IO 是否有周期性尖峰。6.2 Leader 频繁切换先看网络和磁盘还有一种让人头皮发麻的情况ZK 集群的 Leader 频繁切换日志里反复出现LEADER ELECTION。高频切换的后果是什么写请求在选举期间会全部失败所有依赖 ZK 的组件都像癫痫一样抖动。我遇到过的原因有这几类网络抖动。syncLimit太小follower 和 leader 之间的心跳超时follower 误以为 leader 失联开始发起新的选举。排查方法是在三台机器之间做 ping 丢包测试看监控上的网络延迟曲线。磁盘写入变慢。follower 提交事务日志时被 IO 拖住心跳处理不及时被误判为失联。用iostat看磁盘util%如果长期超过 90%基本就是这个原因。JVM Full GC。ZK 是 Java 进程堆内存能塞下几十万个 ZNode但频繁 Full GC 会冻结整个进程心跳自然发不出去。建议给 ZK 配 G1 收集器并把堆大小调到 4GB 或更高节点多的情况下。一个小技巧用echo mntr | nc 127.0.0.1 2181查看实时指标重点看zk_followers、zk_synced_followers、zk_outstanding_requests。其中zk_outstanding_requests如果持续增大说明 Follower 处理不过来堆积了大量待同步请求这是 Leader 端性能瓶颈的前兆。6.3 磁盘空间与日志清理光靠自动清理不够ZK 的事务日志会源源不断增长。虽然在 3.4.0 之后启用了autopurge.snapRetainCount和autopurge.purgeInterval两个参数但自动清理只在“重启后和定期触发”时执行而且默认保留 3 个快照。如果集群跑了一年没重启过快照目录有可能因为事务日志太少而显得没什么问题但一旦遇到业务高峰每天几个 GB 的日志增长完全可能把磁盘打满。我的习惯做法是把dataLogDir和dataDir设为独立目录并在监控里单独盯两块的磁盘使用率。设置autopurge.snapRetainCount5以上避免自动清理过于激进导致“回溯能力不足”。额外写一个 cron 脚本每周手动清理一次旧日志保留最近 3 天双保险。这里还要注意一个细节清理日志不能直接删文件必须用 ZK 的维护命令。直接rm会导致和快照对不上启动时可能出现Bad transaction的异常。正确做法是用zkCleanup.sh脚本或者调用org.apache.zookeeper.server.PurgeTxnLog工具。6.4 节点性能瓶颈读多写多分别怎么扩容ZK 的架构决定了它的扩容逻辑和普通数据库完全不一样。读瓶颈增加观察者Observer节点可以分担读压力。Observer 不参与投票不会增加写路径的成本但可以服务读请求。这个方案在生产里用得很多。写瓶颈没有好办法只能确认是否真的必须让 ZK 承受这么大的写量。很多时候瓶颈不在 ZK 本身而是上层功能设计不合理——比如高频注册/心跳让临时节点反复创建删除。优化方向是减少对 ZK 的写频率而不是给 ZK 加机器。另外所有人都应该知道的红线ZK 的单节点 ZNode 数量不是无限的。默认限制是 100 万个左右由jute.maxbuffer决定单条数据大小实际上限取决于堆内存。当集群里存了海量临时顺序节点比如分布式锁场景下忘记释放会直接把 ZK 堆内存打爆。有一次我看一个测试集群的 ZK 内存飙升到 80% 以上堆占用用echo dump | nc 127.0.0.1 2181一看光是临时节点就有 300 多万个全是某个定时任务里锁没释放导致。这种问题靠加内存只能暂时缓解根因还得从业务代码里找。6.5 你还需要知道的几个四字命令的正确用法ZK 的四字命令是故障排查最好的朋友但很多人只会ruok。我平时最常用的几个命令用途关键输出stat查看节点角色、Zxid、连接数Mode: leader/followerClients列表mntr查看监控指标最适合采集到监控系统zk_server_state、zk_outstanding_requests、zk_znode_count等conf查看当前生效的配置确认参数是否真的修改成功srvr节点运行概况比 stat 更稳定的状态cons当前客户端连接明细能看到每个客户端 IP、会话超时时间如果你把这些命令输出的指标接到 Prometheus、Zabbix 这类监控系统里就形成了一套最基本的 ZK 监控。见过的生产事故里凡是监控做得到位的处理 ZK 问题基本都能在十几分钟内定位监控缺失的只能等业务方报障一个故障折腾半天。我跟所有人讲 ZK 运维时都强调一句话宁可让监控多打一个点也不要让故障自己摸上门。7. 知识体系的最后一环什么时候别用 ZooKeeper聊了这么多 ZK 的好处我也得泼两盆冷水。任何技术都有自己适合的边界ZK 也是这样。这些年见过不少团队因为“ZooKeeper 很牛”就把所有和协调相关的事情都交给它结果给自己挖了坑。7.1 ZK 的天然短板ZK 最大的短板是写性能。它的写操作要经过 Leader 广播到多数节点确认这个“多数派确认”的开销是硬性的。官方给出的极限写吞吐大概在万级 TPS 左右这在大多数协调类场景完全够用但如果把它当消息队列用、当数据库用那是找错人了。它的第二个短板是Watch 机制只能做简单通知不具备复杂的事件流处理能力。如果你需要“事件按顺序回放”“事件补偿”“消息堆积”这些语义ZK 给不了它就是一个轻量级的“状态感知器”不是“事件总线”。还有一个容易被忽略的问题ZK 集群本身也是需要运维成本的。3 个节点至少就要三台机器还要防网络分区、盯磁盘、做备份升级。如果你的业务只是一个简单的注册中心数据规模也不大完全可以考虑用更轻量的方案替代。现在很多团队用 Nacos、Etcd、Consul 来处理服务发现和配置管理它们各有侧重不少场景下比 ZK 更顺手。7.2 选型时的个人判断逻辑我这些年结合自己的使用经验慢慢沉淀了一套选型判断逻辑分享给你参考如果你的核心诉求是“分布式协调原语”比如分布式锁、选主用 ZK因为这套模型最成熟稳定。如果核心诉求是“服务注册发现和配置中心”业务也很现代优先考虑 Nacos 这类有控制台、有配置管理 UI 的产品运维成本低得多。如果系统规模极大读写都很高还要支持多数据中心复制考虑 Etcd 或者基于 Raft 的自研协调层。如果只是在 Hadoop/大数据生态里用那不用想直接用 ZK因为 HBase、Kafka 的老版本都已经深度绑定它。说白了ZK 是那种“你可以不爱它但不能不认识它”的基础设施。哪怕你的新项目不用它去面试大厂分布式系统设计那道题十个有九个都会绕着 ZK 问。学明白它等于在分布式系统这个领域打了一个坚实的地基。另外还有一个思维层面的收获。我从 ZK 的 ZAB 协议里学到的“多数派思维”在很多系统设计里都在起作用——比如 etcd 的 Raft、Paxos 的变体甚至金融系统里的主备切换方案核心思想都是“过半确认 唯一 Leader 日志复制”。你只需要把一个协议弄透其他分布式一致性协议都是换汤不换药。我自己在实际部署中三节点 ZK 集群一年到头几乎不需要人工干预但每一次出问题都跟“配置不合理”“监控缺失”“客户端逻辑错误”这三类原因有关。所以如果你是刚开始接触 ZK不要只盯着部署教程看多花时间理解 ZAB 协议多研究 Curator 的封装逻辑多熟悉四字命令的输出指标。等你能把stat输出里的每一项都说出个所以然来ZooKeeper 这块就可以算真正入门了。最后再分享一个小经验。如果你手头有 ZK 集群我强烈建议你找一个维护窗口主动做一次故障演练手动 kill 掉 Leader 节点观察集群在多长时间内选出新 Leader、客户端是否自动恢复连接。这个过程会暴露非常多在“看着没问题”状态下发现不了的隐患——比如选举时间过长、客户端重试策略不合理、会话超时配置太短等。我自己做完这场演练之后整个集群的稳定性和信心提升了一大截。许多事不亲手做一遍你永远不知道自己还差在哪。 ZooKeeper核心机制与生产实践：从ZAB协议到分布式锁
老话讲“见过猪跑和吃过猪肉是两码事”ZooKeeper 在我这儿就属于“吃了好几年猪肉”的项目。前后在好几个生产环境里和它打交道从最初 Hadoop 集群里陪跑的协调角色到后面自己上手维护、排查脑裂、调 JVM 参数算是把这只“动物园管理员”的脾气摸了个七七八八。这个项目标题叫“ZooKeeper 知多少”我看很多刚入门的朋友对它又爱又怕——爱是因为几乎所有分布式中间件都绕不开它怕是因为它概念多、术语杂什么 ZNode、Watch、ZAB、会话超时听着像天书。这篇就把我知道的、踩过的、调优过的 ZK 经验一次说清楚它到底解决什么问题、核心机制怎么理解、生产环境怎么部署和运维、怎么和 Hadoop 生态整合实战以及那些文档里不会明说的坑。不管你手里是三个节点的开发环境还是上百台机器的生产集群这篇都能给你点实在的东西。1. 先弄明白 ZooKeeper 到底在解决什么问题很多人第一反应是“ZooKeeper 是不是个注册中心”这么说对了一半。它在某些场景下确实能当注册中心用但它的定位远比注册中心要底层。我习惯把它理解成分布式系统里的分布式协调内核。你可以把 ZK 看成一支分布在各台机器上的“小军队”它们通过一套严格协议保证彼此状态永远一致对外提供一套极简的文件系统接口让上层的各种分布式组件用它来达成共识、感知变化、选举主节点。1.1 为什么分布式系统离不开“协调”这件事单机系统里没有协调问题因为就一份数据、一个进程不存在“谁说了算”的分歧。分布式系统一上来问题就全冒出来了。比如说你有 5 台机器共同提供一个服务其中一台挂了剩下 4 台怎么知道要接手它的活再比如多个客户端同时要改一份配置怎么保证大家看到的版本是一致的更麻烦的是网络分区——左边两台机器和右边三台机器暂时联系不上两边都想干活这时候听谁的这些问题本质都是“分布式共识”问题。ZooKeeper 的厉害之处在于它把这种共识能力做成了一个通用的基础设施让上层的 HBase、Kafka、Hadoop 这些系统不用各自发明轮子直接往 ZK 里写几个节点、监听几个事件就能实现主节点选举、集群成员管理、分布式锁、配置下发。它提供的不是一个完整的解决方案而是解决问题的“原语”这句话我建议所有初学者刻在脑子里。1.2 ZooKeeper 在生态里的位置和典型使用场景我见过最经典的比喻是把 ZK 比作“分布式系统的神经系统”。Kafka 用 ZK 保存 broker 列表、选举 controllerHBase 用 ZK 做 HMaster 的选举和 meta 表的定位Hadoop HDFS 用 ZK 做 NameNode 的自动故障转移Dubbo、Curator 这些框架也拿它做服务注册与发现。哪怕是云原生时代Etcd 在功能上也是同类产物很多老系统迁移之前还是离不开 ZK。我整理了几个最常见的实际场景你在理解各个中间件源码时都会碰到场景具体用法依赖的 ZK 特性Leader 选举多个节点竞争创建同一个临时节点谁创建成功谁是主临时节点 节点唯一性服务注册与发现每个服务在指定路径下创建临时顺序节点客户端监听父节点临时节点 Watch 通知分布式锁多个客户端在锁路径下创建临时顺序节点取序号最小者获锁临时顺序节点 Watch配置管理把配置写到 ZNode 上客户端监听变化并动态更新Watch 机制 持久节点集群元数据存储HBase meta 表地址、Kafka broker 列表等持久节点 顺序节点这里要注意一个原则ZK 不适合存大量业务数据。它的设计目标是存储少量的协调状态比如几 KB 的配置、几个字节的选举标记。谁要是脑洞大开往里面写几百 MB 的数据那是把 ZooKeeper 当数据库使了生产环境分分钟教你做人。我后面会专门说这个坑。2. 五句话讲透 ZK 的核心机制别再被概念绕晕学习 ZK 最大的障碍是一堆术语扑面而来ZNode、Watch、Session、Quorum、ZAB、ACL每个单词都认识放在一起就晕。我的经验是不要一开始扎进源码而是先抓住三个核心机制数据模型ZNode、监听机制Watch、一致性协议ZAB。这三件事弄明白了整个 ZK 的骨架就搭起来了。2.1 ZNode既像文件路径又比文件多了一堆脾气ZK 的命名空间看起来极像一个文件系统. /开头一层一层往下挂。比如/hbase/meta-region-server就是 HBase 用来存 meta 表地址的节点。但 ZNode 和普通文件有本质区别节点是分类型的。持久节点Persistent写进去就一直在除非主动删除临时节点Ephemeral和客户端会话绑定客户端会话一断节点自动消失顺序节点Sequential会在你指定的路径后面自动追加一个单调递增的序号比如lock_0000000001。这几种节点组合起来就能玩出选举、锁、注册发现这些花样。节点是有版本号的。每个 ZNode 维护version、cversion、aversion三个版本号对应数据变更次数、子节点变更次数、ACL 变更次数。这让乐观锁式的并发控制成为可能后面讲分布式锁时大家会看到它的威力。节点不能有“部分写入”。要么整个节点数据一次写成功要么不动不存在写了一半的状态。这个特性对上层应用太重要了。我初学的时候老记不住临时节点后来找了个生活化的类比临时节点就是网吧里的上网记录你刷卡上机创建会话记录就产生你下机走人断开会话记录自动注销不需要管理员手动删。这个类比帮我记了好多年。2.2 Watch 机制一次性订阅别指望“推送”ZK 的 Watch 机制让客户端能感知节点变化。客户端可以对某个节点注册 Watch当这个节点数据变化、子节点增减、节点删除时ZK 会向客户端发送一个通知。但这里有两个非常关键的细节新手必踩Watch 是一次性的。触发一次之后这个监听就失效了想继续监听必须重新注册。所以客户端处理完事件后的第一件事就是再注册一次 Watch这个套路我当年忘了写结果线上动态配置只更新了一次后面全不生效。Watch 通知只告诉“你关心的节点发生变化了”不会告诉你变化后的具体数据。收到通知后客户端必须主动再调一次 getData 去拿最新值。还有个容易忽略的点Watch 的触发顺序是异步的但不保证“先到先得”。它只保证“最终你会收到一个通知”而且如果客户端和服务器之间连接断开期间发生的变化在重连后可能不会重新通知——这也是各种 Curator 框架要封装重注册逻辑的原因。2.3 ZAB 协议与 Leader 选举那个让集群“自动分出老大”的机制ZK 集群通常由奇数台机器组成比如 3 台、5 台、7 台。之所以要求奇数是因为它采用了“多数派”决策模型一个写请求只有获得了超过半数节点的确认才算真正提交成功。3 台允许挂 1 台5 台允许挂 2 台。过半机制也决定了 ZK 集群的最小规模是 3 台2 台毫无意义因为挂 1 台就达不到多数派。整个 ZK 的一致性由 ZAB 协议保证它有两个阶段崩溃恢复Leader 选举集群启动或 Leader 挂了时所有节点通过投票选出新的 Leader选出来的 Leader 必须拥有最新的数据。原子广播数据同步Leader 接收写请求把事务广播给所有 Follower超过半数确认后提交。我对 ZAB 的理解是它把“选老大”和“听老大的”这两个过程拆得很干净。选 Leader 用的是 Fast Leader Election 算法实际开发中不用关心太多细节但运维排查时有一个概念必须懂ZXID事务 ID。每个事务都有唯一的递增 ID其中包含了 Leader 的任期信息。选举时 ZK 会比较 ZXID谁的日志最新谁优先当 Leader这样就保证了不会出现新 Leader 数据比旧 Leader 还旧的情况。有朋友会问既然有 Leader客户端读写还是要通过它吗读写走的是另一套逻辑所有节点的写请求都会转发到 Leader而读请求可以由任意节点直接响应。这也是 ZK 的一个经典性能取舍——它天生是“读可扩展、写不扩展”的架构。想靠加机器提升写性能是不可能的写性能由 Leader 和多数派确认的延迟决定但读能力是可以横向加的。2.4 会话Session与超时配置这是一个值得被反复强调的点客户端与 ZK 建立连接后会维护一个会话。会话有两个关键参数sessionTimeout会话超时时间和sessionId会话标识。ZK 通过心跳维持会话默认客户端会以不超过超时时间三分之一的间隔向服务器发送心跳。如果你配置的会话超时太短网络抖动一下就会导致会话过期太长则临时节点删除会变得滞后。实际生产中我一般建议把sessionTimeout设在 10 到 30 秒之间。太短了网络 GC 就能让你“掉线”太长了故障切换时间会拉得很长。HBase、Kafka 各自封装客户端时都有自己默认的超时配置比如 Kafka 老版本默认 6 秒生产环境经常出现“明明 ZK 没挂但 Kafka 报 ZK 超时”的情况十有八九是会话超时配置不够合理而不是 ZK 真挂了。3. 从零搭建一个生产可用的 ZooKeeper 集群纸上谈兵聊完概念接下来聊聊动手。我用一台测试机的简化配置来演示不过生产环境部署完整 3 节点集群的步骤几乎一模一样只有节点数、IP、内存和磁盘的差异。3.1 部署前要做的硬件评估和环境准备ZK 本身非常轻量是个 Java 进程内存占用通常在几百 MB 到 2GB 之间。但它有两个硬性指标常被忽视磁盘 IO 和文件描述符。ZK 的所有写操作先写事务日志TxnLog再定期生成快照Snapshot所以磁盘写入性能直接决定写延迟。我建议系统盘和数据盘分离事务日志目录和快照目录可以分盘放减少相互干扰。至少给 ZK 进程所在用户配置ulimit -n到 65535 以上否则大并发下会报 “Too many open files”。确认 JDK 版本ZK 3.5 以后要求 JDK 8 及以上3.8 之后 JDK 11 也是可用的。一定要避免在 JDK 版本上抠抠搜搜。环境上其实没太多要特别装的东西。官方压缩包解压即用不需要编译。做法是把apache-zookeeper-x.x.x-bin.tar.gz注意认准带-bin的那个包不带 bin 的是源码包下载到服务器解压到/opt/zookeeper然后软链一个不带版本号的路径方便以后升级。3.2 修改核心配置文件 zoo.cfg别忽略每个参数的含义从conf目录复制一份zoo_sample.cfg改成zoo.cfg然后改成下面这个样子tickTime2000 initLimit10 syncLimit5 dataDir/data/zookeeper/snapshot dataLogDir/data/zookeeper/txnlog clientPort2181 maxClientCnxns60 autopurge.snapRetainCount5 autopurge.purgeInterval12 server.1172.16.10.11:2888:3888 server.2172.16.10.12:2888:3888 server.3172.16.10.13:2888:3888几个参数是这么个逻辑tickTimeZK 的最小时间单位单位毫秒。心跳、超时、选举都基于它计算。initLimitFollower 启动后与 Leader 完成数据同步的最大时间单位是 tickTime 的倍数。集群数据量大、网络慢时这个值可以适当调大默认 10 个 tick。syncLimitFollower 与 Leader 之间心跳检测的超时倍数。如果网络经常抖动建议从 5 调到 10。否则 Follower 会被误判为“失联”然后反复进入选举。dataLogDir事务日志独立目录。这个配置决定写性能生产环境务必配置。autopurge.snapRetainCount和autopurge.purgeInterval控制自动清理旧快照和日志避免磁盘被日志撑爆。早期 ZK 不自带清理大家得写 cron 脚本3.4 之后自带自动清理建议打开。配置完后还要在dataDir指向的目录下创建myid文件内容是对应的 server 编号。比如第一台机器echo 1 /data/zookeeper/snapshot/myid。这个文件就像是每台机器的身份证很多新手第一次搭建 3 节点集群失败就是忘了写或者写错了 myid节点一直起不来。三个节点之间的端口也要说清楚2888是 Follower 和 Leader 之间同步数据的端口3888是选举投票端口。这两个端口在防火墙、安全组规则里一定要放通否则节点之间互相发现不了。之前帮朋友排查过一个问题2181 客户端端口通了但 3888 端口被安全组挡了结果集群永远选不出 Leader日志里全是连接拒绝。这个问题极其隐蔽大家一定提前检查。3.3 启动集群和验证健康状态别裸奔启动倒是简单每个节点执行bin/zkServer.sh start但我强烈不建议启动完看一眼“好像起来了”就收工。我会做下面这几步验证看进程状态bin/zkServer.sh status如果输出Mode: leader或Mode: follower说明角色已经选出来了。看端口监听netstat -tlnp | grep 2181。用四字命令ruok检查节点是否健康echo ruok | nc 127.0.0.1 2181如果返回imok说明节点状态正常。用echo stat | nc 127.0.0.1 2181查看角色、Zxid、客户端连接数等关键信息。这里要提醒一件事ZK 自带的 4 字命令ruok、stat、mntr、conf、cons 等默认是开启的但存在一定的安全风险。在公网环境下任何能连到 2181 端口的人都能执行这些命令查看集群状态甚至通过dump看到会话详情。生产环境建议在zoo.cfg中设置4lw.commands.whitelistruok,stat,mntr,conf来限定允许的命令集合同时用安全组或防火墙把 2181 端口限制在内网范围内。3.4 用 zkCli 快速熟悉 ZK 的基本操作命令行是理解 ZK 数据模型最好的老师。进入交互模式bin/zkCli.sh -server 127.0.0.1:2181几条常用指令ls / create /myapp hello get /myapp set /myapp hello2 create -e /tmp_node ephemeral # 临时节点 create -s /seq_node seq # 顺序节点 delete /myapp我建议新手亲手做两个实验实验一验证临时节点的生命周期。用create -e /tmp_node tmp创建一个临时节点然后按CtrlC退出会话再用另一个终端执行ls /你会发现/tmp_node已经消失了。这个实验能让你把“临时节点与会话绑定”的印象刻进脑子里。实验二观察顺序节点的序号。连续执行三次create -s /seq_node seq然后ls /你会看到/seq_node0000000001、/seq_node0000000002、/seq_node0000000003这样的节点。这就是后面分布式锁的基础。命令行还有一个非常实用的调试技巧用get时加上-w参数可以注册一个 Watch然后开另一个窗口set节点数据你会发现第一个窗口立刻收到WATCHER::WatchedEvent通知。这个实验能帮你理解“一次性触发”的含义——触发一次后再 set 就不再有通知了。4. Java 客户端实战自己动手实现一个分布式锁聊完命令行我猜你想知道“代码里到底怎么用”。ZK 官方提供的 Java API 比较底层Curator 框架封装了常用高级功能。但为了让你真正理解原理我先用原生 API 写一个简单的分布式锁再用 Curator 的现成方案做对比这样你既能看懂底层逻辑又能直接用于生产。4.1 原生 ZK API 实现分布式锁的核心逻辑分布式锁的思路其实非常清晰多个客户端要抢一把锁就让它们在同一个父节点下创建临时顺序节点ZooKeeper 保证这些节点的序号是全局唯一的递增的。然后每个客户端检查自己创建的节点是不是所有子节点里序号最小的如果是说明抢到了锁如果不是就监听序号比它小一号的那个节点等它删除后再尝试。这个算法又叫 “lock using ephemeral sequential node”业内用得非常多。代码骨架长这样public class ZkDistributedLock implements AutoCloseable { private final ZooKeeper zk; private final String lockRoot; private final String lockName; private String nodePath; public ZkDistributedLock(String connectString, String lockPath, String lockName) throws Exception { this.lockRoot lockPath; this.lockName lockName; // 连接是异步的这里用 CountDownLatch 等连接建立 CountDownLatch latch new CountDownLatch(1); this.zk new ZooKeeper(connectString, 30000, event - { if (event.getState() Watcher.Event.KeeperState.SyncConnected) { latch.countDown(); } }); latch.await(); // 确保父节点存在 if (zk.exists(lockRoot, false) null) { zk.create(lockRoot, new byte[0], ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT); } } public void lock() throws Exception { // 1. 创建临时顺序节点 nodePath zk.create(lockRoot / lockName -, new byte[0], ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL); // 2. 尝试获得锁 while (!tryAcquire()) { synchronized (this) { wait(); } } } private boolean tryAcquire() throws Exception { ListString children zk.getChildren(lockRoot, false); Collections.sort(children); // 找到自己 String currentNode nodePath.substring(nodePath.lastIndexOf(/) 1); int index children.indexOf(currentNode); // 序号最小获得锁 if (index 0) { return true; } // 监听前一个节点等它消失 String prevNode lockRoot / children.get(index - 1); zk.exists(prevNode, event - { if (event.getType() Watcher.Event.EventType.NodeDeleted) { synchronized (ZkDistributedLock.this) { ZkDistributedLock.this.notifyAll(); } } }); return false; } public void unlock() throws Exception { // 释放锁就是删除自己创建的节点 if (nodePath ! null) { zk.delete(nodePath, -1); } zk.close(); } Override public void close() throws Exception { unlock(); } }这里面有四个非常关键的设计点临时节点的意义防止死锁。拿到锁的客户端如果突然宕机ZK 的会话检测机制会自动删除临时节点锁自然释放后续节点立刻被唤醒。不需要复杂的“锁超时续期”逻辑。监听前一个节点而不是父节点避免惊群效应。如果所有客户端都监听父节点一个节点删除会唤醒所有等待者然后大家疯狂去抢锁大部分都会失败造成无谓的压力。只监听的“前一个节点”就保证同一时刻只有一个客户端会被唤醒这个设计在分布式锁里叫“公平锁”。序号的排序规则。ZooKeeper的顺序节点序号是 10 位数字的补零字符串所以字符串排序和数字排序是一致的。这也是 Files 里顺序节点可以比较的原因。finally 块里的清理动作。unlock一定要放在try-finally中就算业务代码抛异常也要释放锁否则锁被自己一直占着别人永远进不来。4.2 生产环境直接用 Curator不要再重复造轮子原生 API 写一遍是为了理解但生产环境我绝对不会直接用裸 API因为重连、会话恢复、Watch 重注册的细节太容易出错了。Curator 把这些全封装好了还提供了InterProcessMutex这样开箱即用的锁实现CuratorFramework client CuratorFrameworkFactory.builder() .connectString(172.16.10.11:2181,172.16.10.12:2181,172.16.10.13:2181) .sessionTimeoutMs(15000) .connectionTimeoutMs(5000) .retryPolicy(new ExponentialBackoffRetry(1000, 3)) .build(); client.start(); InterProcessMutex lock new InterProcessMutex(client, /locks/order-create); try { if (lock.acquire(5, TimeUnit.SECONDS)) { // 拿到了锁执行业务 } else { // 超时没拿到锁做降级处理 } } finally { lock.release(); } client.close();这里建立客户端时有个细节值得展开一下retryPolicy一定要配。Curator 默认的重试策略是ExponentialBackoffRetry第一次失败后等 1 秒重试第二次等 2 秒第三次等 4 秒。如果集群正在做 Leader 选举客户端暂时连不上没有重试策略的话业务代码直接抛异常。有重试策略就能平稳度过选举期。4.3 配置中心怎么做Watch 的正确使用姿势分布式锁是写路径的经典场景读路径的经典场景是配置中心。思路是把配置写到一个持久节点所有客户端启动时读一次并注册 Watch配置变更时收到通知再去读新值并更新本地缓存。但是这里的坑在于如果客户端与 ZK 的连接断开再重连期间发生的配置变更可能会丢失通知。简单的应对办法是在收到SyncConnected事件重连成功后主动重新读一次配置并重新注册 Watch。Curator 提供了一套NodeCache和PathChildrenCache它们内部实现了重连后的重新注册逻辑用起来非常省心NodeCache cache new NodeCache(client, /config/app1); cache.getListenable().addListener(() - { byte[] data cache.getCurrentData().getData(); // 更新本地配置 }); cache.start();我自己经历过一次事故某个数据平台依赖配置中心做实时开关某天网络抖动导致 ZK 会话重新建立但客户端 Watch 没重新注册线上开关状态一直停留在旧值业务数据多跑了一个多小时才发现。从那以后我定了一条规矩凡是直接使用原生 API 的地方必须处理重连接事件凡是能用 Curator 封装的绝不自己写 Watch 逻辑。5. Hadoop 整合实战HDFS 高可用里 ZK 到底扮演什么角色标题里带着“Hadoop 和 ZooKeeper 整合实战”这部分我就拿 HDFS 高可用HA来讲。很多同学搭过 HDFS HA但只知其然而不知其所以然。这里是 ZK 最典型、最能体现价值的整合场景。5.1 HDFS HA 的架构里ZK 管了哪三件事在 NameNode 高可用架构中两个 NameNode 一个 Active、一个 Standby正常情况下 Active 提供服务Standby 同步 EditLog 待命。当 Active 节点宕机时Standby 需要快速感知并升级为 Active。这个“感知、选举、切换”的过程如果没有一个外部的协调者很容易出现“双主”的脑裂——两个 NameNode 同时以为自己是 Active那整个集群就乱了。ZooKeeper 在这一整套流程中主要做三件事Active NameNode 会在 ZK 上创建一个临时节点/hdfs/ha/nameservice1/ActiveBreadCrumb这个节点的存在就是“我是 Active”的凭证。临时节点嘛节点死了就不存在了。ZKFCZK FailoverController监听这个节点。Active NameNode 崩溃后临时节点自动消失ZKFC 感知到变化。Standby NameNode 通过 ZK 进行选举竞争创建同一个临时节点谁创建成功谁成为新的 Active。这里脑裂防护有个关键机制Standby 成为 Active 之前会先尝试通过 SSH 登录到旧的 Active 上执行fuser -k强制杀掉旧进程fencing隔离再去 ZK 创建节点。即使 SSH 失败了ZK 里的临时节点也会在旧节点会话超时后自动消失形成双重保险。5.2 实际配置中容易踩的坑HDFS HA 整合 ZK 时需要先在 ZK 里初始化 HA 状态存储路径这一步常常被忽略hdfs zkfc -formatZK这个命令会在 ZK 中创建/hdfs/ha等相关节点。如果没初始化之后启动 ZKFC 时它会尝试创建节点但权限不对或路径冲突经常报org.apache.zookeeper.KeeperException$NodeExistsException。另一个坑是edits 共享目录。HA 下两个 NameNode 要共用一个 journals 目录这个和 ZK 没有直接关系但很多新手把这两件事混在一起明明 ZK 状态正常却因为 JournalNode 没配好搞了半天。一般来说在部署之前先分清楚ZK 负责的是活性探测和自动切换JournalNode 负责的是元数据日志共享两者职责完全不同不能混为一谈。生产环境配置了自动故障转移后还有一个非常实用的检查项定期用echo stat | nc zk_ip 2181看各节点的连接数是否均匀。如果有大量客户端连到一个节点说明连接配置里没有把 ZK 地址列表都填进去。ZK 客户端连接串里填多个地址时客户端会随机选择一个进行连接天然地起到负载均衡作用但如果只填一个 IP所有客户端就会集中打到一台机器上这台机器成为瓶颈另外两台却闲着。5.3 整合 Kafka 和 HBase一个模式练百遍肌肉记忆如果你理解了 HDFS HA 的整合套路Kafka 和 HBase 你会发现如出一辙。Kafka 老版本在 ZK 上注册 broker 信息/brokers/ids/0用 ZK 选 controller用 Watch 感知 broker 列表变化。HBase 用 ZK 选 HMaster同时把 meta 表地址写到/meta-region-server。它们都是同一个模式写节点表示状态、监听节点感知变化、竞争节点完成选举。你只要把这个模式吃透看哪个框架的 ZK 整合代码都是十行之内就能猜出大概。这也是我把 ZK 称作“中间件的中枢神经系统”的原因。哪个中间件想进集群一起工作第一步就是先到 ZK 里报个到、占个位置。理解了这一点再看 Kafka 的config/server.properties里zookeeper.connect配置你就能自动脑补出一整套“注册、心跳、选举、感知”的流程。6. 运维经验与故障排查实录全是文档里没有的细节这一节我认为是整篇价值最高的部分。ZK 真正的难点不在部署而在运行期。稳定运行一年半载不出事是常态一出事就是核心链路断裂。下面这些问题我全部在真实环境里碰到过给你一条条拆解排查思路。6.1 会话超时和连接断开不一定是 ZK 挂了“ZK 连接断了”是我遇到最多的一类误报。很多业务报警“ZooKeeper session expired”第一反应是去查 ZK 集群状态但 ZK 三台机器明明都活着角色也正常。这时候真正的问题往往在客户端客户端机器负载高导致 GC 停顿心跳发不出去会话被服务器判定超时。Kafka 里线程“卡死”是典型场景某个消费线程里堵塞了五分钟做重 IOZK 会话过期导致这个 broker 临时节点被删除集群认为该 broker 下线了分区被重新分配。处理完业务线程Broker 重新注册又触发一轮 rebalance。这种“GC 停顿 会话超时 临时节点消失 上游感知重分配”的连锁反应是大数据集群里最常见的慢故障触发器。排查思路大概是先看客户端日志里Session expired前后有没有Full GC的线索比如jstat -gcutil观察老年代增长。再调整sessionTimeout不要墨守默认值。Kafka 里可以调zookeeper.session.timeout.ms适当调大能显著降低误判概率。关注客户端所在机器的 CPU 和 IO 是否有周期性尖峰。6.2 Leader 频繁切换先看网络和磁盘还有一种让人头皮发麻的情况ZK 集群的 Leader 频繁切换日志里反复出现LEADER ELECTION。高频切换的后果是什么写请求在选举期间会全部失败所有依赖 ZK 的组件都像癫痫一样抖动。我遇到过的原因有这几类网络抖动。syncLimit太小follower 和 leader 之间的心跳超时follower 误以为 leader 失联开始发起新的选举。排查方法是在三台机器之间做 ping 丢包测试看监控上的网络延迟曲线。磁盘写入变慢。follower 提交事务日志时被 IO 拖住心跳处理不及时被误判为失联。用iostat看磁盘util%如果长期超过 90%基本就是这个原因。JVM Full GC。ZK 是 Java 进程堆内存能塞下几十万个 ZNode但频繁 Full GC 会冻结整个进程心跳自然发不出去。建议给 ZK 配 G1 收集器并把堆大小调到 4GB 或更高节点多的情况下。一个小技巧用echo mntr | nc 127.0.0.1 2181查看实时指标重点看zk_followers、zk_synced_followers、zk_outstanding_requests。其中zk_outstanding_requests如果持续增大说明 Follower 处理不过来堆积了大量待同步请求这是 Leader 端性能瓶颈的前兆。6.3 磁盘空间与日志清理光靠自动清理不够ZK 的事务日志会源源不断增长。虽然在 3.4.0 之后启用了autopurge.snapRetainCount和autopurge.purgeInterval两个参数但自动清理只在“重启后和定期触发”时执行而且默认保留 3 个快照。如果集群跑了一年没重启过快照目录有可能因为事务日志太少而显得没什么问题但一旦遇到业务高峰每天几个 GB 的日志增长完全可能把磁盘打满。我的习惯做法是把dataLogDir和dataDir设为独立目录并在监控里单独盯两块的磁盘使用率。设置autopurge.snapRetainCount5以上避免自动清理过于激进导致“回溯能力不足”。额外写一个 cron 脚本每周手动清理一次旧日志保留最近 3 天双保险。这里还要注意一个细节清理日志不能直接删文件必须用 ZK 的维护命令。直接rm会导致和快照对不上启动时可能出现Bad transaction的异常。正确做法是用zkCleanup.sh脚本或者调用org.apache.zookeeper.server.PurgeTxnLog工具。6.4 节点性能瓶颈读多写多分别怎么扩容ZK 的架构决定了它的扩容逻辑和普通数据库完全不一样。读瓶颈增加观察者Observer节点可以分担读压力。Observer 不参与投票不会增加写路径的成本但可以服务读请求。这个方案在生产里用得很多。写瓶颈没有好办法只能确认是否真的必须让 ZK 承受这么大的写量。很多时候瓶颈不在 ZK 本身而是上层功能设计不合理——比如高频注册/心跳让临时节点反复创建删除。优化方向是减少对 ZK 的写频率而不是给 ZK 加机器。另外所有人都应该知道的红线ZK 的单节点 ZNode 数量不是无限的。默认限制是 100 万个左右由jute.maxbuffer决定单条数据大小实际上限取决于堆内存。当集群里存了海量临时顺序节点比如分布式锁场景下忘记释放会直接把 ZK 堆内存打爆。有一次我看一个测试集群的 ZK 内存飙升到 80% 以上堆占用用echo dump | nc 127.0.0.1 2181一看光是临时节点就有 300 多万个全是某个定时任务里锁没释放导致。这种问题靠加内存只能暂时缓解根因还得从业务代码里找。6.5 你还需要知道的几个四字命令的正确用法ZK 的四字命令是故障排查最好的朋友但很多人只会ruok。我平时最常用的几个命令用途关键输出stat查看节点角色、Zxid、连接数Mode: leader/followerClients列表mntr查看监控指标最适合采集到监控系统zk_server_state、zk_outstanding_requests、zk_znode_count等conf查看当前生效的配置确认参数是否真的修改成功srvr节点运行概况比 stat 更稳定的状态cons当前客户端连接明细能看到每个客户端 IP、会话超时时间如果你把这些命令输出的指标接到 Prometheus、Zabbix 这类监控系统里就形成了一套最基本的 ZK 监控。见过的生产事故里凡是监控做得到位的处理 ZK 问题基本都能在十几分钟内定位监控缺失的只能等业务方报障一个故障折腾半天。我跟所有人讲 ZK 运维时都强调一句话宁可让监控多打一个点也不要让故障自己摸上门。7. 知识体系的最后一环什么时候别用 ZooKeeper聊了这么多 ZK 的好处我也得泼两盆冷水。任何技术都有自己适合的边界ZK 也是这样。这些年见过不少团队因为“ZooKeeper 很牛”就把所有和协调相关的事情都交给它结果给自己挖了坑。7.1 ZK 的天然短板ZK 最大的短板是写性能。它的写操作要经过 Leader 广播到多数节点确认这个“多数派确认”的开销是硬性的。官方给出的极限写吞吐大概在万级 TPS 左右这在大多数协调类场景完全够用但如果把它当消息队列用、当数据库用那是找错人了。它的第二个短板是Watch 机制只能做简单通知不具备复杂的事件流处理能力。如果你需要“事件按顺序回放”“事件补偿”“消息堆积”这些语义ZK 给不了它就是一个轻量级的“状态感知器”不是“事件总线”。还有一个容易被忽略的问题ZK 集群本身也是需要运维成本的。3 个节点至少就要三台机器还要防网络分区、盯磁盘、做备份升级。如果你的业务只是一个简单的注册中心数据规模也不大完全可以考虑用更轻量的方案替代。现在很多团队用 Nacos、Etcd、Consul 来处理服务发现和配置管理它们各有侧重不少场景下比 ZK 更顺手。7.2 选型时的个人判断逻辑我这些年结合自己的使用经验慢慢沉淀了一套选型判断逻辑分享给你参考如果你的核心诉求是“分布式协调原语”比如分布式锁、选主用 ZK因为这套模型最成熟稳定。如果核心诉求是“服务注册发现和配置中心”业务也很现代优先考虑 Nacos 这类有控制台、有配置管理 UI 的产品运维成本低得多。如果系统规模极大读写都很高还要支持多数据中心复制考虑 Etcd 或者基于 Raft 的自研协调层。如果只是在 Hadoop/大数据生态里用那不用想直接用 ZK因为 HBase、Kafka 的老版本都已经深度绑定它。说白了ZK 是那种“你可以不爱它但不能不认识它”的基础设施。哪怕你的新项目不用它去面试大厂分布式系统设计那道题十个有九个都会绕着 ZK 问。学明白它等于在分布式系统这个领域打了一个坚实的地基。另外还有一个思维层面的收获。我从 ZK 的 ZAB 协议里学到的“多数派思维”在很多系统设计里都在起作用——比如 etcd 的 Raft、Paxos 的变体甚至金融系统里的主备切换方案核心思想都是“过半确认 唯一 Leader 日志复制”。你只需要把一个协议弄透其他分布式一致性协议都是换汤不换药。我自己在实际部署中三节点 ZK 集群一年到头几乎不需要人工干预但每一次出问题都跟“配置不合理”“监控缺失”“客户端逻辑错误”这三类原因有关。所以如果你是刚开始接触 ZK不要只盯着部署教程看多花时间理解 ZAB 协议多研究 Curator 的封装逻辑多熟悉四字命令的输出指标。等你能把stat输出里的每一项都说出个所以然来ZooKeeper 这块就可以算真正入门了。最后再分享一个小经验。如果你手头有 ZK 集群我强烈建议你找一个维护窗口主动做一次故障演练手动 kill 掉 Leader 节点观察集群在多长时间内选出新 Leader、客户端是否自动恢复连接。这个过程会暴露非常多在“看着没问题”状态下发现不了的隐患——比如选举时间过长、客户端重试策略不合理、会话超时配置太短等。我自己做完这场演练之后整个集群的稳定性和信心提升了一大截。许多事不亲手做一遍你永远不知道自己还差在哪。