ZAB

ZAB（Zookeeper Atomic Broadcast）协议概述

ZAB 协议是为分布式协调服务 ZooKeeper 专门设计的一种原子广播协议，用于保证分布式系统中数据的一致性和主从节点数据的同步。ZooKeeper 在分布式系统中扮演着重要角色，如配置管理、命名服务、分布式锁等，而 ZAB 协议是 ZooKeeper 实现这些功能的核心保障。

1. ZAB 协议的主要阶段和工作机制

• 消息广播阶段（Broadcast Phase）

  • 工作原理：在 ZooKeeper 集群中，当客户端发送一个写请求（如创建节点、更新节点数据等）到主节点（Leader）时，主节点会将这个写请求转化为一个事务 Proposal（提议），并为这个提议分配一个全局唯一的递增的事务 ID（zxid）。然后，主节点通过一个 FIFO（先进先出）的队列将提议广播给所有的从节点（Follower）。从节点接收到提议后，会将其写入本地的磁盘事务日志中，然后向主节点发送一个 ACK（确认）消息。当主节点收到超过半数（Quorum）的从节点的 ACK 消息后，就会向所有从节点发送一个提交（Commit）消息，通知它们可以将这个事务应用到内存数据库中，从而完成整个消息广播过程。
  • 示例：假设一个 ZooKeeper 集群有一个主节点和三个从节点，客户端发送一个写请求 “创建节点 /node1”。主节点将这个请求转换为一个带有 zxid 的提议，如 zxid = 100，然后广播给三个从节点。从节点收到提议后记录到事务日志，再发送 ACK 给主节点。当主节点收到至少两个从节点的 ACK 后，发送 Commit 消息，此时所有节点将这个事务应用到内存数据库，完成节点 /node1 的创建。

• 崩溃恢复阶段（Recovery Phase）

  • 工作原理：当主节点出现故障（如宕机）时，ZAB 协议会进入崩溃恢复阶段。在这个阶段，ZooKeeper 集群会选举出一个新的主节点。选举的依据主要是节点的 zxid 和数据完整程度。拥有最大 zxid 的节点通常有更大的优势成为新的主节点，因为它的数据是最新的。新主节点选举出来后，它需要和其他从节点进行数据同步。新主节点会检查从节点的 zxid，对于从节点中已经提交（Commit）但新主节点还没有的事务，新主节点会将这些事务重新广播给其他从节点，以保证所有节点的数据一致性。对于从节点中未提交的事务（处于 Proposal 阶段），新主节点会根据事务的 zxid 决定是丢弃还是重新广播这些事务。
  • 示例：如果主节点在广播一个事务（zxid = 200）但还没发送 Commit 消息时崩溃，集群开始选举新主节点。假设一个从节点已经收到并记录了这个事务，另一个从节点还没收到。新主节点选举出来后，会根据自己的事务日志和从节点的情况，决定是否重新广播这个事务，确保所有节点的数据最终一致。

2. ZAB 协议与其他分布式一致性协议的比较

• 与 Paxos 协议比较

  • 相似点：ZAB 协议和 Paxos 协议都用于解决分布式系统中的一致性问题。它们都通过多轮消息传递和投票机制来达成共识。例如，在节点选举和事务提交过程中，都需要多数节点的同意。
  • 不同点：ZAB 协议相对 Paxos 协议在设计上更偏向于支持 ZooKeeper 的功能特点。ZAB 协议是一个主从模式的协议，有明确的主节点来主导事务的广播，而 Paxos 协议没有这样明确的主从之分，其角色在选举过程中是动态变化的。另外，ZAB 协议在消息广播阶段的流程相对 Paxos 协议更加简洁明了，更适合 ZooKeeper 这种对写操作有一定顺序要求的场景。

• 与 Raft 协议比较

  • 相似点：Raft 和 ZAB 都有领导者（Leader）的概念，并且在领导者选举和数据复制方面有相似的机制。例如，两者都需要多数节点的支持来选举领导者，并且领导者在数据复制过程中起到关键作用。
  • 不同点：Raft 协议在选举过程中有明确的任期（Term）概念，通过任期来保证选举的顺序和合法性。ZAB 协议则通过 zxid 来保证事务的顺序和节点的更新程度。在数据复制方面，ZAB 协议的消息广播和提交过程与 Raft 协议的日志复制和提交过程在细节上有所不同，ZAB 协议的重点在于保证 ZooKeeper 事务的原子广播和顺序性。