ZAB协议(ZooKeeper Atomic Broadcast)入门

什么是 ZAB（Zookeeper 原子广播协议）？

ZAB 协议确保 Zookeeper 复制按顺序完成，并且还负责领导节点的选举和任何失败节点的恢复。 在 Zookeeper 生态系统中，leader 节点是一切的核心； 每个集群都有一个leader节点，其余的节点是follower。 所有传入的客户端请求和状态更改首先由领导者接收，负责将其复制到所有追随者（及其本身）。 所有传入的读取请求也由其自身内的领导者及其追随者进行负载平衡。

ZAB有哪些职责？

顺序维护：
如果在 X 的发送者提交事务 Y 之后接收到事务 X，则 Y 必须在 X 之前被排序。如果客户端在 X 之后发送 Z，那么 Z 必须在 X 之前被排序。

可靠的交付：
如果事务“A”已由一台服务器提交，那么所有服务器都提交它很重要。

总顺序维护：
客户端状态的更改在 Zookeeper 世界中称为事务。 如果某个服务器在事务 Y 之前提交了事务 X，则所有服务器都必须复制相同的顺序。 只要所需的最小节点数（多数）达到，就会进行交易复制。 在节点发生故障并恢复的情况下，该特定节点应该能够复制在其停机期间提交的所有事务。

ZAB是如何实施的？

Zookeeper 围绕两阶段提交协议构建，允许它复制所有事务，同时牢记上述所有设计原则。领导节点在收到客户端状态更改请求后生成交易并为其分配序列号。然后它将这些交易发送到所有的跟随者节点并等待他们的确认。

When receiving ACKs from a quorum, commit calls are sent to the quorum
for all the transactions. A follower checks the sequel number of the
issued transaction and only commits it if it doesn’t have any
outstanding transactions in the queue.

当收到来自quorum的 ACK 时，所有事务的提交调用都会发送到quorum。follower检查发出的事务的序列号，只有在队列中没有任何未完成的事务时才提交它。

一个节点只有在拥有法定数量的跟随者节点时才能成为领导者节点。如果领导节点出现故障，将调用恢复协议，其中涉及以下阶段：

Election of a new leader
Discovery across the cluster.
Synchronization of transactions.
Broadcast of relevant data.

下一阶段很重要，因为这是所有追随者与新的可能的领导者取得联系以努力获取有关最近接受的交易的信息的时候。这是必要的，因为这是跨集群的更新事务序列的产生方式。

下一步是同步，基本完成了协议的恢复工作。通过使用由领导者提供的更新数据，集群中的所有副本都被同步。

领导者将其历史中存在的交易发送给所有追随者，如果追随者发现他们的历史落后于领导者，他们就会开始确认传入的交易。当收到来自仲裁的 ACK 时，将发送提交消息；这是可能的/潜在的领导者实际上成为集群的新领导者的地方。

参考

Zookeeper Atomic Broadcast Protocol (ZAB) and implementation of Zookeeper. - CloudKarafka, Apache Kafka Message streaming as a Service