一句话答案

Raft 将一致性分解为 Leader 选举、日志复制、安全性三个子问题，多数派同意即提交，比 Paxos 更易理解和实现。

核心要点

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 通过简单的日志匹配机制统一处理。

三、分布式事务

追问与易错

追问方向：

• Raft 脑裂怎么解决？
• 日志复制和提交的区别？
• Raft 和 Paxos 优缺点？

易错点：

• ❌ Raft 两个 Leader 会脑裂——新 Leader term 更大旧自动降级
• ❌ Leader 活着就不丢数据——需复制到多数节点

💡 记忆锚点

Raft 像班级选班长：随机倒计时谁先喊"选我"谁当候选人（随机超时），超过半数同学举手就当选（多数派投票），班长负责记笔记再抄给全班（日志复制），班长请假就重新选（term递增，旧班长自动让位）。三件事：选领导、抄笔记、保安全。