ZooKeeper高可用集群需至少3个奇数节点、自定义Docker网络、持久化配置与数据，并通过角色验证和故障模拟确保容错能力。
要实现具备高可用特性的 ZooKeeper 集群，核心不是堆机器，而是让集群能自动容错、选举和恢复。Docker 提供了轻量、一致、可复现的运行环境，正好匹配 ZooKeeper 对节点行为确定性和网络可控性的要求。关键不在“能不能跑”，而在“故障时会不会断服务”。
必须用奇数节点且不少于3个
ZooKeeper 的 Quorum 机制依赖“过半数原则”做决策：写操作需同步到多数节点才成功，Leader 选举也需获得超过半数投票。因此：
- 2 节点：任意一节点宕机，剩余节点无法构成多数（1/2 ≤ 0.5），集群立即不可写，存在脑裂风险
- 3 节点：允许 1 个节点故障，仍保有 2 票（2/3 > 0.5），服务持续可用 —— 这是生产环境最低可行配置
- 5 节点：可容忍 2 节点同时宕机，适合对 SLA 要求更高的场景
注意：节点数必须为奇数，偶数节点不会提升容错能力，反而增加选举复杂度和资源开销。
必须使用自定义 Docker 网络
默认 bridge 网络不支持容器名解析，而 ZooKeeper 集群节点间靠 server.x=hostname:2888:3888 相互发现和通信。若 DNS 失效，整个集群将无法完成初始同步或故障重选。
- 先创建专用网络：docker network create zk-net
- 所有容器启动时加参数：--network zk-net
- 为每个容器指定明确 hostname（如 zk1、zk2、zk3），其他节点就能直接用该名字访问
- 避免混用 host 网络或暴露 2888/3888 端口到宿主机 —— 这些是集群内部通信端口，不应被外部干扰
配置与数据必须持久化
容器重启后若丢失 myid 或 zoo.cfg，ZooKeeper 将无法识别自己身份；若 dataDir 清空，则历史数据和会话状态全毁 —— 这直接导致“高可用”变成“假可用”。
- 在宿主机提前建好结构化目录，例如：/opt/zk/zk1/{data,logs,conf}
- 每个 data 子目录下写入唯一 myid 文件（内容仅为数字 1/2/3）
-
zoo.cfg 在所有节点保持完全一致，包含全部 server.x 条目，例如：
server.1=zk1:2888:3888
server.2=zk2:2888:3888
server.3=zk3:2888:3888 - 启动时用 -v 挂载 data、logs、conf 目录，确保配置与数据不随容器生命周期消失
验证高可用不能只看启动成功
真正体现高可用的是故障发生后的系统行为。启动完成后务必做两件事：
- 查角色：进入任一容器执行 zkCli.sh -server zk1:2181，再输入 stat，确认输出中有 Mode: leader 或 Mode: follower
- 模拟故障：用 docker stop 停掉当前 Leader 容器，等待 10–20 秒，观察其余节点日志是否出现新选举过程，并最终稳定为新的 Leader + Follower 组合
- 故障期间用客户端连接剩余存活节点，执行 create /test "ok" 和 get /test，验证读写未中断、数据一致
