zookeeper保证一致性的协议ZAB

一、  ZAB 协议介绍

ZAB (Zookeeper Atomic Broadcast 原子广播协议) 协议是为分布式协调服务ZooKeeper专门设计的一种支持崩溃恢复的一致性协议。基于该协议，ZooKeeper 实现了一种主从模式的系统架构来保持集群中各个副本之间的数据一致性。

分布式系统中leader负责外部客户端的写请求。follower服务器负责读跟同步。这时需要解决俩问题。

1. Leader 服务器是如何把数据更新到所有的Follower的。

2. Leader 服务器突然间失效了，集群咋办？

因此ZAB协议为了解决上面两个问题而设计了两种工作模式，整个 Zookeeper 就是在这两个模式之间切换：

1. 原子广播模式：把数据更新到所有的follower。

2. 崩溃恢复模式：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 崩溃了还能保证数据一致吗？当 Leader 崩溃会进入崩溃恢复模式。其实主要是对如下两种情况的处理。

1. Leader 在复制数据给所有 Follwer 之后崩溃，咋搞？

2. Leader 在收到 Ack 并提交了自己，同时发送了部分 commit 出去之后崩溃咋办？

针对此问题，ZAB 定义了 2 个原则：

1. ZAB 协议确保 执行那些已经在 Leader 提交的事务最终会被所有服务器提交。

2. ZAB 协议确保 丢弃那些只在 Leader 提出/复制，但没有提交的事务。

至于如何实现确保提交已经被 Leader 提交的事务，同时丢弃已经被跳过的事务呢？关键点就是依赖上面说到过的 ZXID了。

四、 ZAB 特性

1. 一致性保证

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

1. 全局有序(Total order)

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

1. 因果有序(Causal order)

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

1. 高可用性

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

1. 可恢复性

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

五、 ZAB 和 Paxos 对比

相同点：

1. 两者都存在一个类似于 Leader 进程的角色，由其负责协调多个 Follower 进程的运行.

2. Leader 进程都会等待超过半数的 Follower 做出正确的反馈后，才会将一个提案进行提交.

3. ZAB 协议中，每个 Proposal 中都包含一个 epoch 值来代表当前的 Leader周期，Paxos 中名字为 Ballot

不同点：

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