一句话答案

ZAB 是 Zookeeper 的原子广播协议，两种模式：崩溃恢复（选主+数据同步）和消息广播（过半确认提交）。

核心要点

ZAB（ZooKeeper Atomic Broadcast）协议： ZooKeeper 使用的原子广播协议，保证分布式数据的一致性。

ZAB 的两种模式：

① 恢复模式（Recovery Mode）
   触发条件：Leader 崩溃、集群启动、网络分区恢复
   目标：选出新 Leader + 数据同步
   流程：
     1. 选举阶段：选出拥有最大 ZXID（事务ID）的节点作为准 Leader
     2. 发现阶段：准 Leader 收集各 Follower 的最新事务
     3. 同步阶段：准 Leader 将最新数据同步给所有 Follower
     4. 同步完成，多数 Follower 确认 → 进入广播模式

② 广播模式（Broadcast Mode）
   触发条件：Leader 选举完成 + 数据同步完毕
   目标：处理客户端写请求
   流程：
     1. 客户端写请求 → Leader
     2. Leader 生成事务提案（Proposal），分配全局递增 ZXID
     3. Leader 将 Proposal 发给所有 Follower
     4. Follower 写入本地日志 → 返回 ACK
     5. Leader 收到半数以上 ACK → 发送 Commit
     6. Follower 收到 Commit → 提交事务

ZAB vs Raft 对比：

维度	ZAB	Raft
设计目标	高可用的顺序广播协议（ZooKeeper 专用）	通用分布式共识算法
Leader 选举	选拥有最大 ZXID 的节点	随机超时 + 多数投票（日志最新者优先）
任期标识	epoch（纪元）	term（任期）
日志标识	ZXID（epoch + counter 组合的 64 位 ID）	term + logIndex
数据同步	恢复模式有专门的同步阶段（DIFF / TRUNC / SNAP）	通过 AppendEntries 逐步对齐
模式切分	显式分为恢复模式和广播模式	无显式模式切分，选举和日志复制无缝衔接
读请求	默认 Follower 可读（可能读到旧数据），可通过 sync 强制读 Leader	默认读 Leader（强一致）

相同点：

• 都是 Leader-based 的共识协议（单 Leader 负责写入）
• 都需要多数节点（Quorum）确认才能提交
• 都保证已提交的日志不会丢失
• 都通过心跳机制检测 Leader 存活

关键差异总结： ZAB 是为 ZooKeeper 量身定制的，侧重于主备模式下的原子广播和崩溃恢复；Raft 是通用共识算法，更强调可理解性和工程友好性。从实现角度看，ZAB 的恢复阶段更复杂（需要处理多种同步场景），而 Raft 通过简单的日志匹配机制统一处理。

三、分布式事务

追问与易错

追问方向：

• ZAB 和 Raft 核心区别？
• Leader 选举过程？
• ZK 适合做注册中心吗？

易错点：

• ❌ ZK 能保证高可用——ZK 是 CP 选举期间不可用
• ❌ ZAB 和 Paxos 完全一样——增加了崩溃恢复

💡 记忆锚点

ZAB 两种模式像公司运营：恢复模式=董事会换届（选ZXID最大的当Leader，同步账本给所有人）；广播模式=日常经营（Leader发提案，过半股东签字就生效）。和Raft的核心区别：ZAB为ZK量身定做有专门的恢复阶段，Raft更通用更好理解。