一致性协议之 ZAB

ZAB协议介绍

ZAB (Zookeeper Atomic Broadcast 原子广播协议) 协议是为分布式协调服务ZooKeeper专门设计的一种支持崩溃恢复的一致性协议。基于该协议，ZooKeeper 实现了一种主从模式的系统架构来保持集群中各个副本之间的数据一致性；分布式系统中leader负责外部客户端的写请求。follower服务器负责读跟同步。
ZAB协议设计了两种工作模式用来满足以上功能，整个 Zookeeper 就是在这两个模式之间切换：

• 原子广播模式：把数据更新到所有的follower。
• 崩溃恢复模式：Leader发生崩溃时，如何恢复。

原子广播

消息广播机制可以认为是简化版的 2PC协议，就是通过如下的机制保证事务的顺序一致性的：

1. leader从客户端收到一个写请求后生成一个新的事务并为这个事务生成一个唯一的ZXID，
2. leader将将带有 zxid 的消息作为一个提案(proposal)分发给所有 FIFO队列。
3. FIFO队列取出队头proposal给follower节点。
4. 当 follower 接收到 proposal，先将 proposal 写到硬盘，写硬盘成功后再向 leader 回一个 ACK。
5. FIFO队列把ACK返回给Leader。
6. 当leader收到超过一半以上的follower的ack消息，leader会进行commit请求，然后再给FIFO发送commit请求。
7. 当follower收到commit请求时，会判断该事务的ZXID是不是比历史队列中的任何事务的ZXID都小，如果是则提交，如果不是则等待比它更小的事务的commit(保证顺序性)

崩溃恢复

消息广播过程中，Leader 崩溃了主要产生2个问题：
Leader 在复制数据给所有 Follwer 之后崩溃，怎么办？
Leader 在收到 Ack 并提交了自己，同时发送了部分 commit 出去之后崩溃，怎么办？
针对这两个问题，ZAB 定义了 2 个原则（依赖ZXID实现）：

• ZAB 协议确保执行那些已经在 Leader 提交的事务最终会被所有服务器提交。
• ZAB 协议确保丢弃那些只在 Leader 提出/复制，但没有提交的事务。

ZAB特性

• 一致性保证

可靠提交(Reliable delivery) ：如果一个事务 A 被一个server提交(committed)了，那么它最终一定会被所有的server提交

• 全局有序(Total order)

假设有A、B两个事务，有一台server先执行A再执行B，那么可以保证所有server上A始终都被在B之前执行

• 因果有序(Causal order)

如果发送者在事务A提交之后再发送B,那么B必将在A之后执行

• 高可用性

只要大多数（法定数量）节点启动，系统就行正常运行

• 可恢复性

当节点下线后重启，它必须保证能恢复到当前正在执行的事务

ZAB 和 Paxos 对比

相同点：

• 两者都存在一个类似于 Leader 进程的角色，由其负责协调多个 Follower 进程的运行
• Leader 进程都会等待超过半数的 Follower 做出正确的反馈后，才会将一个提案进行提交
• ZAB 协议中，每个 Proposal 中都包含一个 epoch 值来代表当前的 Leader周期，Paxos 中名字为 Ballot

不同点：

• ZAB 用来构建高可用的分布式数据主备系统（Zookeeper），Paxos 是用来构建分布式一致性状态机系统