分布式系统一致性（ZAB协议）

ZAB（ZooKeeper Atomic Broadcast）

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

算法模型

• 它是一种基于Quorum投票的冗余控制算法机制, Quorom是一种分布式系统中常用的,用来保证数据冗余和最终一致性的投票算法。

一致性

• ZAB协议是一种弱一致或者说最终一致协议，并不是强一致。

对比其他协议

• Paxos: 首先个人认为ZAB协议不是Paxos的变种，我的感觉是他们是针对一个问题的两种解决方法， Paxos协议完全去中心化的模型，ZAB协议是有中心的模型。ZAB协议在理解和工程实现更容易一些。

• 2PC(3PC): 相比二阶段和三阶段提交，ZAB协议的性能更好，原因在于2PC, 3PC需要等到所有的成员反馈或者超时才能进行下一步操作，ZAB协议只需要收到大多数的反馈即可进行下一步。

基本术语

• Leader服务器: 所有的事务必须有全局唯一的服务器处理，这样的服务器称为Leader服务器。

• Follower服务器: 集群中非Leader服务器称为Follower服务器。

• Zxid：ZooKeeper的事务id，全局唯一，每次ZooKeeper的状态进行更新的时候，Zxid 都会增加。也就是说，Zxid的值越大，说明对应的ZooKeeper集群的数据是越新的。Zxid 的值有64位，其中高 32 位是 epoch 的值，低32位代表的是在同一个Leader周期内的事务id。

• ZAB 中的节点有三种状态

• following：当前节点是跟随者，服从 leader 节点的命令。

• leading：当前节点是 leader，负责协调事务。

• election/looking：节点处于选举状态。

模式

ZAB协议包括2种基本模式崩溃恢复和消息广播。

• 崩溃恢复：当服务启动，或者Leader服务器因为网络中断，崩溃，重启等异常情况时，Leader服务器不可用，这是ZAB协议会进入重新选举Leader阶段，这个阶段叫做崩溃恢复。

• 消息广播：对于客户端的事物请求，类似于2PC, Leader服务器为事务生成一个Proposal，将其发送个Follower服务器，根据反馈，决定是否事务提交。这个过程称为消息广播。

崩溃恢复

选举Leader

• 每个Follower都向其他所有的节点发送投票信息，选举自己为Leader。投票中主要包含的信息为Zxid和server id。
• 同时，每个Follower都会在本地保存一个已收到的投票集合，保存了收到的投票信息。
• Follower收到其他节点的投票信息后，会跟自身进行相应的比较：首先比Zxid的大小，如果相等，再比较server id的大小。如果收到的投票的Zxid或server id 比自己的大，那么更新本地已收到的投票信息以及更改自己的选票并重新发送选票给其他节点。
• 如果本地收到的投票信息中已经有某个节点获得了半数以上的投票，发送投票，将该节点选为 Leader，然后停止本节点的选举过程。

模拟过程

• STEP 1：处于LOOKING状态的A发起一次选主请求，并将请求广播至B、C节点，而此时B、C也恰好处于LOOKING状态。

• STEP 2：B、C节点处理A的选主消息，其中，B接受A的提议，C拒绝A的提议：

• A的选主消息让B和C此时都获得了A节点选主的结果（A投票给A，记录为<A, A>），记录该信息，作为后续判断大家是否达成一致的标准。

• STEP 3：B将处理结果通知A、C

• B更新了自己的投票，从投票给自己变成投票给A，因此根据协议的定义，需要将该消息扩散出去。而C由于拒绝了A的提议，因此，无需扩散消息；

• B将消息扩散给A和C的同时，A和C也就了解了B的投票信息，可以更新本地的投票信息表，例如上面经过B的扩散后，A知道了B节点的投票信息，C知道了A和B节点的投票信息。

• STEP 4：C同时也发起选主

• STEP 5：A、B分别处理C的选主请求

• 这里A和B判断得出C是最合适的Leader，因此A和B都更新自己的候选Leader为C，同时由于C的消息，A和B都更新自身维护的投票信息，增加C的投票信息。

• STEP 6：A、B将更新后的信息扩散到其他节点

• 因为在第五步中A和B分别将自己的候选Leader变成了C，因此需要将该信息通知到其他节点，其他节点在收到新的投票信息后会更新本地的投票信息列表，如上图。

• STEP 7: 选主结束

数据同步

• 完成Leader选举之后，Leader服务器确认事务日志中Proposal是否被集群中的过半Follow提交了，这个过程称为数据同步。

• 正常同步（Follower Zxid 小于 Follower Zxid): Leader和每个Follower建立一个队列，讲所有Follower未提交的事务用Proposal方式发送过去，并且在每个Proposal消息之后接commit消息，表示事务提交。等到Follower服务器同步了所有已经提交的Proposal之后，Follower加入到可用的Follower队列中，进行后续操作。

• 处理需要丢弃Proposal同步（Follower Zxid 大于 Follower Zxid)：需要回退日志，忽略大于Leader 日志的Proposal。
  

• Server1 作为Follower加入集群中，需要忽略p3的Proposal。

消息广播

• 在ZooKeeper集群完成同步后，整个集群就可以对外提供服务，也就是可以接收客户端的事务请求了。此时就进入了广播阶段。

流程如下：

• 当Leader接收到来自客户端的事务请求时，会生成对应的事务，然后根据Zxid的顺序将每个事务发送给所有的 Follower。
• Follower根据接收到的消息顺序，依次处理事务。事务处理完成后，将结果反馈给 Leader。
• 当Leader收到超过半数的Follower的确认信息后，就会向所有的Follower发送commit 消息。
• Follower 接收到 Leader 的 commit 消息后，就会进行事务的提交。

说明

• 消息广播过程和2PC类似，其中最大的改变时重要有过半的Follower 正常反馈可以提交事务，Leader就能发出commit 请求，无须等待所有节点反馈。虽然这样可能有数据不一致问题，但是通过崩溃恢复过程能够保证最终一致。