ZooKeeper 三节点集群别只看“都启动了”：用故障矩阵验证选举与数据同步

三台 ZooKeeper 进程显示running只能证明它们各自启动并不能证明法定多数、Leader 选举、数据复制和客户端故障转移有效。本文围绕myid、成员配置、四字命令、会话语义与滚动故障设计一套可重复的三节点验收矩阵。重点不是背配置而是让每个结论都有观察点、有预期、有失败解释。先明确三节点集群承诺什么ZooKeeper 使用法定多数形成可用服务。三节点集群允许同时失去一个投票成员失去两个后剩余节点即使进程还活着也不能继续形成多数并接受正常写入。这是为了避免网络分区两边都认为自己正确。“容忍一台故障”还带着条件客户端必须配置多个地址网络必须允许成员间通信存活节点的数据足够新磁盘和时钟没有破坏协议假设。三节点并不是把同一配置复制三份就自动高可用。上线验收要分别回答四个问题成员是否认出彼此是否能稳定选出唯一 Leader写入是否复制到 Follower客户端在节点变化后是否按预期重连。每个问题使用独立证据不以一张管理页面代替。myid是身份映射不是随便写的序号每台机器的数据目录里保存一个myid文件其值必须与成员配置中的服务器编号一致。假设配置有server.1、server.2、server.3三台机器的myid应分别是 1、2、3并且没有重复。常见错误有三类复制目录后忘记改myid数据目录实际挂载位置与配置不一致主机名在某些节点无法解析。它们可能表现为进程启动后反复选举、只看到单机模式或日志里持续连接失败。配置审查不要只对比文件文本还要从每台主机验证解析结果、目标端口和数据目录权限。成员地址应使用稳定的内部名称或地址不把会变化的容器临时 IP 当永久身份。分清客户端端口和成员通信端口客户端通过clientPort连接 ZooKeeper集群成员还需要法定人数通信与 Leader 选举端口。防火墙若只放行客户端端口监控可能显示三个可访问的孤立进程却无法组成 ensemble。为端口建立一张连通矩阵每台节点到另外两台的成员端口都必须验证客户端来源只访问客户端端口运维探测接口限制在管理网。不要为了省事在节点间开放全部端口。TLS、认证和网络策略应按实际版本与威胁模型配置。至少避免把未认证的管理命令暴露到公网并确认监控命令白名单。诊断功能越方便越需要清楚它向谁开放。启动后先取三个最小证据第一是角色证据三台节点中应看到一个 Leader 和两个 Follower。第二是成员证据每台都识别同一套成员而不是各自组成不同视图。第三是数据证据通过客户端创建一个临时测试路径从另外两个地址分别读取相同版本和值。角色只在当前时刻成立重启后 Leader 可能变化所以自动化不要断言固定机器永远是 Leader。应该断言“恰好一个 Leader、其余为 Follower且成员总数符合预期”。读取相同值也不代表所有读取都具备线性一致语义。客户端若要求读取前看到某个已完成写入需要理解 ZooKeeper 的顺序保证并在必要时使用同步机制。测试文档应明确是验证复制结果还是验证跨客户端的更强时序预期。用故障矩阵代替一次性重启第一行测试停止一个 Follower。预期是集群保持多数、现有客户端继续工作、停止节点恢复后追赶数据。观察 Leader 是否稳定、写入是否成功、恢复节点的 zxid 是否向最新值靠拢。第二行测试停止当前 Leader。预期会发生短暂不可用和重新选举随后另一个节点成为 Leader。客户端可能收到连接丢失或操作结果未知应用不能简单把超时等同于写入失败。使用请求业务标识或读取确认避免盲目重复产生副作用。第三行测试同时停止两个节点。预期剩余节点无法形成多数写请求不可继续。这一项非常重要若单节点仍对外宣称可写说明测试访问的并非预期集群或架构中存在危险的旁路。第四行测试网络分区一台与另外两台隔离。多数侧应继续服务少数侧退出有效领导关系。恢复网络后观察它重新同步而不是人工删除数据目录强制“修复”。删除目录会丢失诊断证据并可能掩盖真正的版本或配置问题。第五行测试磁盘压力。将测试环境的数据盘逼近告警线确认快照、事务日志和清理策略按预期工作。不要在生产盘直接写满通过隔离卷或容量限制复现。磁盘故障与网络故障的恢复动作不同告警也应分开。会话与临时节点必须单独验收很多系统使用 ZooKeeper 不是为了普通键值而是依赖会话和 ephemeral 节点。客户端短暂断网时会话可能仍然有效超过会话超时后临时节点会被删除。服务发现和主节点竞争逻辑必须正确处理这两个阶段。测试时创建带唯一标识的临时节点短断网后恢复确认它仍存在再让连接超过会话超时确认旧临时节点消失客户端以新会话重新注册。若业务只检查 TCP 重连成功可能漏掉会话已经更换这一事实。watch 通知是一次性触发语义应用收到事件后通常需要重新读取状态并重新设置观察。不要把 watch 当可靠消息队列也不要假设每次中间变化都会逐条送达。故障恢复测试应关注最终状态能否收敛而非只统计通知数量。快照、事务日志与恢复要成套设计数据目录和事务日志目录应有明确位置、容量与备份策略。仅备份配置无法恢复业务状态仅复制正在写入的文件也未必得到一致备份。根据版本和运维要求使用支持的快照与恢复流程并定期在隔离环境演练。自动清理要保留足够的快照和事务日志用于恢复与排障不能只追求磁盘空闲。每次升级前记录版本、集群成员、配置摘要、数据量和当前角色滚动升级时一次只处理一个节点等其重新加入并同步后再继续。监控至少覆盖节点角色、连接数、未处理请求、延迟、数据大小、打开文件数、磁盘水位和选举频率。频繁切换 Leader 即使服务尚可访问也说明网络、GC、磁盘或资源隔离存在问题。结语ZooKeeper 高可用不是“三台都亮绿灯”而是多数派规则在真实故障下仍按预期工作。把身份、端口、角色、复制、会话和恢复写成故障矩阵逐项保存观察证据才能知道集群究竟容忍了什么。一次主动演练发现的问题通常比生产中的一次被动选举便宜得多。