细读经典第一期——从Paxos到Zookeeper 分布式一致性原理与实践（３）

上一篇文章过了一下paxos算法的核心，按照书中的章节，会介绍一下chubby分布式锁中的一致性部分，这块我们先行掠过，等全书结束之后，当作附加章节回顾本章

那么直接进入后面的章节， 也是本书的核心内容。

---

目录

目录

第四章

4.1 初识ZK

4.2 ZAB

4.2.1消息广播

4.2.2崩溃恢复

---

第四章

4.1 初识ZK

ZK是Chubby的开源实现

ZK的几个特性，最好是理解+熟记，也可以是熟记+理解，我反而觉得熟记+理解更容易融会贯通

ZK的功能：

 

4.2 ZAB

ZAB全称Zookeeper Atomic Broadcast，原子消息广播协议

ZAB整体分为两个状态，一个是崩溃恢复，一个是消息广播，消息广播用于实现一致性消息的传递，而崩溃恢复用于达成宕机重启节点或新加入节点与原网络分区之间一致性恢复。

4.2.1消息广播

ZAB的消息广播类似于２ＰＣ，只是在第二阶段事务提

所有的Follower要么正常反馈Leader提出的Proposal，要么就抛弃Leader的Proposal，同时，当Follower中超过半数的Follower已经ACK之后，整个集群就已经可以开始提交Proposal了。

所以你可能会问，那么这个过程中，Leader宕机了，那么不就又存在部分Follower的不一致情况了么，这就需要崩溃恢复过程，继续完成整个集群一致性的工作。这里我们按下不表，先把整个广播消息的过程看完。

广播的过程就是建立TCP连接的过程，在整个广播过程中，Leader会为每个请求创建一个全局唯一且单调递增的ID，也即ZXID（64bit数字，高32bit，Leader周期的epoch编号，低32bit单调递增计数器），用于保证消息之间的因果关系。Leader会为每个Follower服务器创建一个单独的队列，然后将要广播的Proposal依次放入队列之中（可以类比MQ），并且FIFO的进行发送，每一个Follower在拿到Proposal之后都会WAL，之后向Leader返回ACK（可以类比MQ的commitlog）。当Leader收到半数以上的Follower的ACK消息之后，就会广播Commit消息通知各个Follower对事务进行提交。

4.2.2崩溃恢复

我们之间说到如果在Leader进行广播的过程中出现崩溃，那么系统就需要崩溃恢复让集群重新达成一致性。说白了，就是需要让所有Follower更合理的投票，让被选出的Leader感知自己被选举，同时继续发挥Leader的作用。

这里书中没有提到的一点是，一个新选举出来的Leader必须要先依次commit前一个Leader将会commit的所有Proposal，然后才能开始提交自身Proposal，即便这些Follower还未收到commit消息，即便收到这条消息的机器数还不过半。

这里为了更好的说明这个问题。我们需要稍微展开一下，这里是参考了multi-paxos、raft和zab协议的核心区别_Saintyyu的博客-CSDN博客文章中的内容，我用自己的话和理解再说一遍，也可以对比原文看看，核心问题是我一致性是用于实现分布式事务还是分布式主备，如果是分布式事务，那么我会采用悲观的策略，例如2PC，第二阶段的失败和成功，与第一阶段应该保持一样，第二阶段确定失败，那么我会回滚一阶段，而分布式主备系统，如果Follower已经WAL落盘，那么意味着这些Proposal理应都在所有的Follower上执行成功，对比起来有点回滚和前滚的味道。

理解了上面的内容，你会更好理解ZAB的以下两个基本特性：

1. 已经在Leader上提交的事务，需要最终被所有服务器提交(Follower已经WAL，则前滚Proposal）
2. ZAB需要确保丢弃只在Leader上被提出的Proposal（Follower并没有WAL，则丢弃Proposal）

 往下要进入最枯燥乏味的ZAB算法描述阶段，这里会抽象的描述整个ZAB的过程，了解其中的专业名词和主要步骤思路是核心思路。

下期见，恭喜发财