ZooKeeper ZAB协议概述
ZAB协议是ZooKeeper一致性的核心保障。
ZAB协议概述
ZAB设计目标：
| 目标 | 说明 |
|---|---|
| 原子性 | 消息要么全部提交要么全部失败 |
| 顺序性 | 所有消息全局有序 |
| 可恢复性 | Leader崩溃后能恢复一致状态 |
两种模式：
| 模式 | 说明 |
|---|---|
| 消息广播 | 正常状态处理写请求 |
| 崩溃恢复 | Leader故障后恢复 |
协议特点：
- 主从架构：Leader主导，Follower跟随
- 过半机制：过半确认即可提交
- 全局顺序：ZXID保证消息顺序
ZAB与Paxos区别：
| 方面 | ZAB | Paxos |
|---|---|---|
| 角色 | Leader主导 | 多Proposer |
| 顺序 | 全局严格有序 | 可能乱序 |
| 恢复 | 专门恢复机制 | 无专门设计 |
提示：ZAB为ZooKeeper定制设计，比Paxos更适合协调服务场景。
消息广播流程
两阶段提交：
text
阶段1 - 提议：
Leader → Follower: 发送Proposal提议
阶段2 - 提交：
Follower → Leader: 发送ACK确认
Leader收到过半ACK后 → 所有节点: 发送Commit提交
详细流程：
text
1. Leader收到写请求
2. Leader生成Proposal提议（包含ZXID）
3. Leader发送Proposal给所有Follower
4. Follower接收Proposal，写入日志，发送ACK
5. Leader统计ACK数量
6. 收到过半ACK后，Leader发送Commit
7. 所有节点执行Commit，提交事务
8. Leader响应客户端成功
提议结构：
| 字段 | 说明 |
|---|---|
| zxid | 事务ID（高32位epoch + 低32位计数） |
| type | 操作类型 |
| path | 节点路径 |
| data | 节点数据 |
过半确认机制：
text
假设3节点集群：
Leader收到2个ACK（自己+1个Follower）即可提交
无需等待全部Follower确认
消息顺序保证：
text
Leader按ZXID顺序发送提议
Follower按顺序接收和处理
保证所有节点看到相同的消息顺序
性能优化：
| 优化 | 说明 |
|---|---|
| 流水线 | Leader连续发送提议，不必等前一个提交 |
| 批量 | 多提议打包发送，减少网络往返 |
- 异步提交 | 过半ACK后立即提交，不等全部 |
注意：消息广播确保原子性和顺序性，是ZooKeeper写请求的基础。
要点总结
- ZAB保证原子性、顺序性、可恢复性
- 消息广播采用两阶段提交：提议+提交
- 过半ACK即可提交，不等待全部
- ZXID保证消息全局有序
- 流水线和批处理优化性能
- ZAB为ZooKeeper定制，比Paxos更适合协调服务
📝 发现内容有误？点击此处直接编辑