ZooKeeper 主备切换原理

ZooKeeper 通过 ZAB（ZooKeeper Atomic Broadcast）协议 实现主备切换，核心是选举出唯一 Leader（主节点），Follower（备节点）在 Leader 故障时重新选举新 Leader 以保证服务连续性。

📖 ZAB 协议核心流程

flowchart TD
    A[集群启动] --> B{所有节点 LOOKING}
    B --> C[投票选举 Leader]
    C --> D{超过半数支持?}
    D -->|是| E[节点转为 LEADER / FOLLOWER]
    D -->|否| C
    
    E --> F[Leader 正常运行]
    F --> G{Follower 心跳超时?}
    G -->|否| F
    G -->|是| H[Follower → LOOKING]
    H --> I[触发新一轮选举]
    I --> C

⚡ 选举机制详解

2.1 初始选举

集群启动时，所有节点均为 LOOKING 状态，通过投票选举出 Leader。

投票依据（优先级）：

最终获得超过半数节点支持的节点成为 Leader，其余节点转为 FOLLOWER 状态。

2.2 Leader 故障检测

• Follower 定期向 Leader 发送心跳包
• 若超过 tickTime * syncLimit 未收到 Leader 响应，判定 Leader 故障
• Follower 重新进入 LOOKING 状态，触发新一轮选举

2.3 重新选举

新选举仍基于 zxid 和 myid 优先级，最终选出新 Leader，集群恢复正常读写服务。

写请求 → Leader 处理
读请求 → Follower 可处理（减轻 Leader 负载）

🔧 数据同步

新 Leader 产生后：

1. 将自身的事务日志同步给所有 Follower
2. 确保集群中所有节点数据一致
3. Follower 同步完成后才正式对外提供服务

⚙️ K8s 环境中的应用

在 K8s 原生生态中，etcd 已逐步取代 ZooKeeper 成为默认的分布式协调存储，但 ZK 在 Hadoop/大数据生态中仍广泛使用。

关联文档

• ../core/K8s 核心概念 — K8s 基础
• ../core/K8s 组件详解
• Share-nothing 无共享架构 — 分布式架构基础 — etcd 与分布式存储

最后更新：2026-06-01

关联文档

• K8s 核心概念 — 基础概念
• K8s 组件详解 — 组件说明