ZAB 协议（ZooKeeper Atomic Broadcast）是 ZooKeeper 保证数据一致性的核心算法。正如你所提到的，ZAB 协议主要包含两种基本模式：崩溃恢复（Crash Recovery） 和 消息广播（Message Broadcast）。

以下是这两种模式的详细解析：

---

1. 崩溃恢复模式 (Crash Recovery)

这是 ZAB 协议为了保证系统高可用和数据一致性而设计的特殊模式。

• 触发时机：

  • Zookeeper 集群刚启动时。
  • 当前的 Leader 节点崩溃、重启或网络中断。
  • Leader 节点失去了过半（Quorum）Follower 节点的联系。

• 主要目的：

  • 选举出一个新的 Leader。
  • 确保新的 Leader 拥有所有已提交（Committed）的事务。
  • 将集群中所有节点的数据与新 Leader 进行同步，达到一致状态。

• 核心流程：

  1. Leader 选举 (Election)： 集群进入选举状态，所有节点通过投票选出新的 Leader。通常拥有最大 ZXID（事务 ID，表示数据最新）的节点会被选为 Leader。
  2. 数据同步 (Synchronization)：
     • 新 Leader 确认后，Follower 节点需要连接 Leader 并同步数据。
     • ZAB 协议保证：丢弃那些只在旧 Leader 上提出但没有被提交的事务；保留并提交那些已经在旧 Leader 上提交的事务。
  3. 完成恢复： 当集群中过半的机器与该 Leader 完成数据同步后，ZAB 协议就会退出恢复模式，进入消息广播模式。

---

2. 消息广播模式 (Message Broadcast)

当集群已经选出了 Leader，且完成了数据同步，系统就进入正常运行状态，即消息广播模式。

• 触发时机：

  • 集群状态健康，Leader 和 Follower 之间保持心跳，且完成了初始化同步。
  • 有客户端发起写请求时。

• 主要机制：

  • 类似于两阶段提交（2PC），但移除了中断逻辑，只需要“过半”节点同意即可提交。
  • 所有的写请求都由 Leader 处理。

• 核心流程：

  1. Proposal（提议）阶段：
     • Leader 接收到写请求，生成一个全局唯一的单调递增事务 ID (ZXID)。
     • Leader 将该事务封装成一个 Proposal 消息，并按照 FIFO（先进先出）队列顺序广播给所有 Follower。
  2. Ack（响应）阶段：
     • Follower 收到 Proposal 后，将其写入本地事务日志。
     • 写入成功后，Follower 向 Leader 发送 ACK 确认消息。
  3. Commit（提交）阶段：
     • 一旦 Leader 收到过半（Majority/Quorum）节点的 ACK，就认为该事务可以提交。
     • Leader 向所有 Follower 发送 Commit 消息，并同时在本地应用该事务。
     • Follower 收到 Commit 消息后，将事务应用到内存状态机中。

---

总结对比

简单的一句话概括：
ZAB 协议通过崩溃恢复保证了 Leader 的选举和数据初始化一致性，通过消息广播保证了在正常运行时集群数据的高效复制和最终一致性。