1. 为什么要把 ZooKeeper 从 Kafka 里拆出来单独部署很多人第一次接触 ZooKeeper都是在搭 Kafka 的时候。下载 Kafka 压缩包解压里面自带一个zookeeper-server-start.sh跟着教程敲一行命令Kafka 就跑起来了。这个流程太顺了顺到很多人根本没意识到那个被顺手启动的 ZooKeeper其实是一个阉割版的临时方案。Kafka 自带的 ZooKeeper 有几个明显的局限。第一它和 Kafka 共用同一台机器的资源CPU、内存、磁盘 IO 都在抢一旦 ZooKeeper 所在的节点负载高了Kafka 的元数据操作就会跟着抖动。第二它默认是单节点没有集群的高可用能力ZooKeeper 一挂整个 Kafka 集群的控制器选举、Topic 元数据管理全部停摆。第三版本升级很被动Kafka 发行版里捆绑的 ZooKeeper 版本往往偏旧你想单独升级 ZooKeeper 修复某个 bug几乎不可能因为改了可能和 Kafka 的兼容性对不上。所以当集群规模上去之后把 ZooKeeper 独立出来单独搭一套集群几乎是必然选择。独立部署之后ZooKeeper 可以跑在专门的节点上资源隔离三节点或五节点组成集群具备容灾能力版本也能自己控制。Kafka 那边只需要在server.properties里把zookeeper.connect指向你独立集群的地址就行剩下的交给 ZooKeeper。这篇文章就围绕两件事展开一是怎么从零把一套独立的 ZooKeeper 集群搭起来二是搭完之后怎么确认它的版本、状态和运行情况。内容偏实操我会把每一步背后的原因讲清楚也会把我在实际部署中踩过的坑一并说出来。适合正在做 Kafka 集群规划、或者想把现有 ZooKeeper 从 Kafka 里剥离出来的同学参考。2. 独立 ZooKeeper 集群的部署前规划2.1 节点数量为什么必须是奇数ZooKeeper 集群的节点数有个硬性规律用奇数不用偶数。常见的是 3 节点和 5 节点。原因在于 ZooKeeper 的选举和写操作都依赖过半机制Quorum。所谓过半就是超过一半的节点同意操作才算通过。假设你有 3 个节点过半数是 2。挂掉 1 个还剩 2 个仍然能凑够过半数集群可用。假设你有 4 个节点过半数也是 34 的一半是 2超过 2 就是 3。挂掉 1 个还剩 3 个刚好够挂掉 2 个还剩 2 个不够了。也就是说4 节点的容灾能力和 3 节点一样都是只能挂 1 个但多了一台机器的成本。这就是为什么偶数节点没有意义。5 节点的过半数也是 3可以容忍挂掉 2 个。所以节点数越多容灾能力越强但写操作的延迟也会上升因为每次写都要等更多节点确认。生产环境里3 节点适合中小规模5 节点适合对可用性要求更高的场景。再往上7 节点就很少见了因为延迟收益比不划算。注意ZooKeeper 集群的节点数一旦确定后期扩容非常麻烦需要重新分配事务日志和快照还要处理数据同步。所以规划阶段就要想清楚宁可多留一台也别搭完就后悔。2.2 硬件和系统层面的准备ZooKeeper 本身对资源的需求不算高它主要吃内存和磁盘 IO。内存方面JVM 堆建议给 2G 到 4G具体看你的数据量。ZooKeeper 的数据全部放在内存里堆太小会导致频繁 GC堆太大又浪费而且 GC 停顿时间会变长。我的经验是中小规模集群给 2G 堆就够节点多、znode 数量大的场景给 4G。磁盘方面ZooKeeper 的写操作会先写事务日志transaction log再写内存数据库。事务日志的写入是顺序追加对磁盘的顺序写性能要求较高。如果条件允许把事务日志和数据快照分到不同的磁盘上能明显提升写性能。用 SSD 当然更好但机械盘也不是不能用关键是别和其他高 IO 的服务共用一块盘。系统层面需要提前做几件事。第一关闭防火墙或者开放 ZooKeeper 需要的端口默认是 2181客户端连接、2888集群内数据同步、3888选举通信。第二配置好主机名和 hosts 解析ZooKeeper 的配置文件里用主机名比用 IP 更清晰但前提是每台机器都能正确解析其他节点的主机名。第三时间同步集群内节点时间差太大会导致选举异常用 NTP 把时间对齐。2.3 版本选择与 JDK 依赖ZooKeeper 的版本选择有个基本原则选稳定版别追最新。3.4.x 和 3.5.x 是两个长期被广泛使用的分支3.6.x 和 3.7.x 也逐步成熟。3.5 之后的版本在动态配置、TLS 支持上有改进但如果你只是做 Kafka 的元数据管理3.4.14 或 3.5.9 这种经过大量生产验证的版本反而更省心。JDK 方面ZooKeeper 3.4.x 用 JDK 8 就行3.5 及以上建议 JDK 8 或 JDK 11。注意别用太新的 JDK比如 JDK 17 在某些老版本 ZooKeeper 上会有模块化相关的兼容问题。我一般会在部署前先确认目标机器上的java -version如果版本不对要么换 JDK要么换 ZooKeeper 版本别硬上。3. 从零搭建三节点 ZooKeeper 集群的完整过程3.1 下载与解压别用 Kafka 里那个第一步就是去 Apache 官网下载独立的 ZooKeeper 发行包。注意不要从 Kafka 的 libs 目录里拷那个 jar 包来用那个是给 Kafka 内嵌启动用的缺少完整的配置文件和启动脚本。下载地址在 Apache ZooKeeper 的官方发布页选apache-zookeeper-x.x.x-bin.tar.gz这个带 bin 的包不带 bin 的是纯源码包没法直接跑。下载完传到三台机器上解压到统一目录比如/opt/zookeeper。我习惯把版本号也带在目录名里比如/opt/zookeeper-3.5.9这样以后升级的时候能并存回滚也方便。解压命令很简单tar -zxvf apache-zookeeper-3.5.9-bin.tar.gz -C /opt/ mv /opt/apache-zookeeper-3.5.9-bin /opt/zookeeper-3.5.9三台机器都做同样的操作保证路径一致。路径一致的好处是配置文件可以完全复用不用每台改路径。3.2 配置文件 zoo.cfg 的逐项拆解ZooKeeper 的核心配置文件是conf/zoo.cfg。解压后conf目录下有个zoo_sample.cfg复制一份改名为zoo.cfg再改。下面是我常用的配置内容逐项说明tickTime2000 initLimit10 syncLimit5 dataDir/data/zookeeper/data dataLogDir/data/zookeeper/logs clientPort2181 server.1zk-node1:2888:3888 server.2zk-node2:2888:3888 server.3zk-node3:2888:3888tickTime是 ZooKeeper 的基本时间单位单位毫秒默认 2000。它决定了心跳间隔和超时计算的基础。initLimit是 follower 和 leader 之间初始连接时能容忍多少个 tick10 乘以 2000 毫秒就是 20 秒意思是 follower 启动后要在 20 秒内完成和 leader 的数据同步否则算失败。syncLimit是运行期间 follower 和 leader 之间心跳的超时容忍5 乘以 2000 就是 10 秒。dataDir是数据快照目录dataLogDir是事务日志目录。这两个分开配置是性能优化的关键前面说过事务日志是顺序写单独放一块盘能减少竞争。如果只有一块盘至少目录分开别混在一起。clientPort是客户端连接端口默认 2181。server.X这几行是集群成员列表格式是server.节点ID主机名:数据同步端口:选举端口。节点 ID 是 1 到 255 之间的整数必须和后面要创建的myid文件内容一致。提示主机名zk-node1这些必须在每台机器的/etc/hosts里能解析到对应 IP否则启动时会报找不到地址。如果不想配 hosts直接写 IP 也行但 IP 变了就要改配置不如主机名灵活。3.3 myid 文件最容易漏掉的一步zoo.cfg里写了server.1、server.2、server.3但 ZooKeeper 怎么知道自己是哪一个靠的就是dataDir目录下的myid文件。这个文件里只有一个数字对应server.X里的 X。在 node1 上echo 1 /data/zookeeper/data/myidnode2 写 2node3 写 3。注意dataDir目录要先创建好myid文件要放在dataDir根目录下不是子目录。我见过有人把 myid 放到dataDir/version-2里结果启动报错找不到排查半天。三台机器的myid内容必须唯一重复了会导致集群启动异常。这是部署时最常见的低级错误之一但一旦踩了报错信息不一定直观所以务必在启动前核对一遍。3.4 启动顺序与日志观察配置和 myid 都就绪后就可以启动了。启动脚本在bin/zkServer.sh命令是/opt/zookeeper-3.5.9/bin/zkServer.sh start三台机器都要执行。启动顺序没有严格要求但建议一台一台来观察日志确认没问题再启下一台。日志在logs目录下文件名类似zookeeper.out或者看dataLogDir旁边的日志目录。启动后用zkServer.sh status查看状态/opt/zookeeper-3.5.9/bin/zkServer.sh status正常的话一台会显示Mode: leader另外两台显示Mode: follower。如果三台都显示standalone说明集群没组起来通常是 myid 或 server.X 配置有问题。如果某台显示Mode: leader但其他两台连不上检查端口和防火墙。注意第一次启动时如果三台几乎同时启动选举可能会多花几秒。如果超过 30 秒还没选出 leader去看日志里的Cannot open channel to X at election address这类错误基本是网络或端口问题。4. 集群跑起来之后怎么确认版本和运行状态4.1 用四字命令查版本stat 和 srvrZooKeeper 提供了一组四字命令Four Letter Words用来快速查询运行状态。查版本最直接的是stat和srvr。用法是通过nc或者telnet连到 2181 端口发命令echo stat | nc 127.0.0.1 2181返回内容里会有一行Zookeeper version: 3.5.9-...这就是当前运行的版本。srvr命令类似但输出更简洁也会带版本信息echo srvr | nc 127.0.0.1 2181如果nc没装用telnet 127.0.0.1 2181进去手动敲stat也行。注意四字命令默认在 3.5 之后有白名单限制如果返回stat is not executed because it is not in the whitelist需要在zoo.cfg里加一行4lw.commands.whiteliststat,srvr,ruok,conf然后重启。4.2 从启动脚本和 jar 包反查版本有时候 ZooKeeper 已经在跑但你不方便连端口或者四字命令被禁了。这时候可以从另外两个地方看版本。第一个是zkServer.sh脚本本身。执行/opt/zookeeper-3.5.9/bin/zkServer.sh version这个命令会直接打印出版本号不需要连接服务。它的原理是读取lib目录下的 jar 包名。所以第二个方法就是看 jar 包ls /opt/zookeeper-3.5.9/lib/ | grep zookeeper你会看到类似zookeeper-3.5.9.jar的文件版本号一目了然。这个方法最可靠因为 jar 包名就是版本不会骗人。4.3 用客户端连接验证集群可用性版本确认了还得验证集群真的能用。用zkCli.sh连上去/opt/zookeeper-3.5.9/bin/zkCli.sh -server zk-node1:2181连上之后敲ls /看看根节点下有什么。默认会有zookeeper这个节点。然后可以创建一个测试节点create /test-node hello再get /test-node看能不能读到值。接着断开换连 node2 和 node3重复get /test-node如果三台都能读到同样的值说明数据同步正常集群工作正常。这个验证步骤很重要因为有时候status显示 leader/follower 正常但实际数据同步有问题只有真正读写一次才能确认。5. 把 Kafka 指向独立 ZooKeeper 的配置改动5.1 Kafka 端 zookeeper.connect 的写法独立 ZooKeeper 集群搭好之后Kafka 那边只需要改一个配置。在 Kafka 的config/server.properties里找到zookeeper.connectzookeeper.connectzk-node1:2181,zk-node2:2181,zk-node3:2181把三个节点都写上用逗号分隔。这样即使其中一个 ZooKeeper 节点挂了Kafka 还能连其他的。注意后面不要带 chroot 路径除非你确实想把 Kafka 的数据隔离到某个子节点下。如果带 chroot写法是zk-node1:2181,zk-node2:2181,zk-node3:2181/kafka但那个/kafka节点必须提前创建好否则 Kafka 启动会报错。改完配置重启 Kafka。重启后观察 Kafka 日志如果看到Connected to zookeeper并且没有反复重连的日志说明连接正常。5.2 迁移过程中的数据一致性风险如果是把现有 Kafka 从自带 ZooKeeper 迁移到独立 ZooKeeper风险比全新搭建大得多。因为 Kafka 的元数据broker 注册、Topic 配置、分区 leader 信息全在 ZooKeeper 里直接换地址会导致 Kafka 找不到原来的元数据集群可能起不来。正确的做法是先停掉 Kafka把原 ZooKeeper 的数据目录整体拷贝到新集群的对应节点上保证数据一致然后再改zookeeper.connect并启动。或者更稳妥的方式是新集群搭好后用 Kafka 自带的迁移工具或者手动重建 Topic 元数据。但手动重建风险高生产环境建议在低峰期做并且提前备份。提示迁移前一定要备份原 ZooKeeper 的dataDir和dataLogDir这是最后的退路。我见过有人直接改配置重启结果 Kafka 起不来原数据又没备份最后只能重建集群。6. 部署和运维中那些文档不会写的坑6.1 磁盘写满导致 ZooKeeper 拒绝服务ZooKeeper 有个特性当磁盘空间不足时它会主动拒绝写操作甚至停止服务。这是为了防止事务日志写不进去导致数据损坏。但问题是它的日志里不一定直接说磁盘满了可能报的是No space left on device或者更隐晦的IOException。我的做法是给dataDir和dataLogDir所在的磁盘设监控使用率超过 80% 就告警。另外ZooKeeper 不会自动清理旧的事务日志和快照需要配置autopurge.snapRetainCount和autopurge.purgeIntervalautopurge.snapRetainCount3 autopurge.purgeInterval24意思是保留最近 3 份快照每 24 小时清理一次。不配这个日志会一直涨迟早把盘写满。6.2 客户端连接数被打满ZooKeeper 默认的maxClientCnxns是 60意思是单个客户端 IP 最多 60 个连接。如果 Kafka 集群的 broker 多或者有其他客户端频繁连接很容易打满。打满之后新连接会被拒绝报Too many connections。解决办法是在zoo.cfg里调大这个值比如maxClientCnxns200。但别调太大否则单个客户端可能耗尽服务端资源。更好的做法是排查为什么会有这么多连接是不是客户端没正确关闭连接或者连接池配置有问题。6.3 选举端口被占用导致集群分裂ZooKeeper 的选举端口默认是 3888数据同步端口是 2888。如果这两个端口被其他进程占用或者防火墙没放行集群会分裂成多个小集群每个都以为自己有 leader。这种情况很危险因为客户端可能连到不同的分区看到不一致的数据。排查方法是看日志里的Looking for leader和Notification time out这类信息然后用netstat -tlnp | grep 3888确认端口监听情况。部署前把防火墙规则配好别等出问题了再查。6.4 版本不一致导致的兼容问题如果集群里三台机器的 ZooKeeper 版本不一样比如两台 3.5.9一台 3.4.14启动时可能能跑但运行中会出现各种奇怪的问题比如数据同步失败、选举异常。ZooKeeper 要求集群内所有节点版本一致至少大版本要一致。所以部署时一定要核对每台机器的 jar 包版本用前面说的ls lib | grep zookeeper确认。升级时也要滚动升级先升 follower再升 leader别三台一起换。7. 日常巡检该看哪些指标集群搭好只是开始日常运维才是重头戏。我一般会定期看几个关键指标。第一个是zk_server_state确认 leader 和 follower 的角色分布正常没有出现多个 leader。第二个是zk_avg_latency和zk_max_latency延迟突然升高往往意味着磁盘 IO 或网络有问题。第三个是zk_outstanding_requests这个值持续大于 0 说明有请求堆积服务端处理不过来。这些指标可以通过四字命令mntr获取echo mntr | nc 127.0.0.1 2181返回的是一堆键值对可以接入监控系统做趋势分析。另外ruok命令用来做存活检查返回imok表示服务正常适合放在健康检查脚本里。巡检频率看集群规模中小规模每天看一次就行大规模或者业务高峰期可以做到分钟级采集。关键是别等出事了才去看平时有基线数据异常时才能快速判断。8. 关于版本查看这件事再补充两个实用技巧前面说了stat、srvr、zkServer.sh version和看 jar 包这几种方法。再补充两个场景。第一个是如果你只有客户端连接权限没有服务器登录权限可以用zkCli.sh连上去之后有些版本支持version命令但并非所有版本都有所以不保证通用。更稳的方式还是四字命令。第二个是如果你在容器环境里ZooKeeper 跑在容器内宿主机上可能没有nc或者telnet。这时候可以用docker exec进容器容器里一般有bash和nc或者直接用zkServer.sh version。如果容器镜像精简到连zkServer.sh都没有那就只能看镜像 tag 或者挂载的 jar 包了。我个人在实际操作中的体会是版本查看这件事看似简单但在故障排查时特别重要。因为不同版本的 ZooKeeper 在配置项、四字命令白名单、日志格式上都有差异确认版本能帮你快速定位问题范围。所以每次接手一个新集群我第一件事就是确认版本然后再看配置和状态。这个习惯帮我省了不少时间。
