我的生态
🧭
Java 面试指南覆盖面试高频考点，助你从容应对技术面试

    ZAB 协议

    ZooKeeper 的一致性保证来自于 ZAB 协议。

    ZAB（ZooKeeper Atomic Broadcast）是 ZooKeeper 的核心协议，它保证：

    1. 消息原子性：消息要么在所有节点都提交，要么都不提交
    2. 消息顺序性：消息按全局顺序提交
    3. Leader 崩溃恢复：Leader 崩溃后能快速恢复

    【架构权衡】 ZAB 是专门为 ZooKeeper 设计的协议，它结合了 Paxos 的思想和两阶段提交的效率。在 Leader 选举和消息广播之间切换，是 ZAB 的核心设计。

    一、核心问题 🔴

    1.1 ZAB 两种模式

    ZAB 两种运行模式：

1. 消息广播（Broadcast）
   └─ 正常运行状态
   └─ Leader 接收请求，广播给所有 Follower
   └─ 等待多数 Follower 确认后提交

2. 崩溃恢复（Recovery）
   └─ Leader 崩溃后触发
   └─ 重新选举 Leader
   └─ 同步数据到新 Leader

    1.2 Leader 选举

    Leader 选举算法（Fast Leader Election）：

每个 Server 有两个 ID：
├─ serverId：服务器 ID（配置时指定，越大越优选）
└─ zxid：事务 ID（越大表示数据越新）

选举规则：
1. 优先比较 zxid（数据最新）
2. zxid 相同则比较 serverId（越大越优选）

投票格式：(serverId, zxid)

    二、消息广播流程

    消息广播流程（两阶段提交）：

1. Leader 收到请求
   └─ 生成 zxid

2. Leader 广播 PROPOSAL
   └─ 发送给所有 Follower

3. Follower 收到 PROPOSAL
   └─ 写入本地日志
   └─ 发送 ACK 给 Leader

4. Leader 收到多数 ACK
   └─ 广播 COMMIT

5. Follower 收到 COMMIT
   └─ 提交本地事务

    三、落地 Checklist

    • 节点数：生产环境至少 3 节点，推荐 5 节点
    • 节点分布：跨机架/跨机房部署
    • Leader 监控：监控 Leader 切换次数
    • 数据同步：监控数据同步延迟