深入理解zab协议崩溃恢复的过程

如果对zab没有概念，可以先看这篇：读懂zookeeper一致协议：zab原子协议

目录

Zab 节点三种状态

节点的其他持久属性

Zab崩溃恢复 的四个阶段（从zab协议设计的理论上而言）

1、选举阶段（Leader Election）

2、发现阶段（Descovery）

3、同步阶段（Synchronization）

4、广播阶段（Broadcast）

---

zab的崩溃恢复过程就是围绕leader选举以及发现、同步、广播四个阶段来展开。

Zab 节点三种状态

• Following：当前节点是跟随者，服从 Leader 节点的命令。
• Leading：当前节点是 Leader，负责协调事务。
• Election/Looking：节点处于选举状态，正在寻找 Leader。

代码实现中，多了一种状态：Observing 状态
这是 Zookeeper 引入 Observer 之后加入的，Observer 不参与选举，是只读节点，跟 Zab 协议没有关系。

如果想了解更多zookper集群的角色，可以看这篇：三分钟明白zookeeper集群中的三种角色Leader、Follower和observer

节点的其他持久属性

• history：当前节点接收到事务 Proposal 的Log
• acceptedEpoch：Follower 已经接受的 Leader 更改 epoch 的 newEpoch 提议。
• currentEpoch：当前所处的 Leader 年代
• lastZxid：history 中最近接收到的Proposal 的 zxid（最大zxid）

Zab崩溃恢复 的四个阶段（从zab协议设计的理论上而言）

1、选举阶段（Leader Election）

节点在一开始都处于选举节点，只要有一个节点得到超过半数节点的票数，它就可以当选准 Leader，只有到达第三个阶段（也就是同步阶段），这个准 Leader 才会成为真正的 Leader。

Zookeeper 规定所有有效的投票都必须在同一个 轮次 中，每个服务器在开始新一轮投票时，都会对自己维护的 logicalClock 进行自增操作。

每个服务器在广播自己的选票前，会将自己的投票箱（recvset）清空。该投票箱记录了所受到的选票。
例如：Server_2 投票给 Server_3，Server_3 投票给 Server_1，则Server_1的投票箱为(2,3)、(3,1)、(1,1)。（每个服务器都会默认给自己投票）

前一个数字表示投票者，后一个数字表示被选举者。票箱中只会记录每一个投票者的最后一次投票记录，如果投票者更新自己的选票，则其他服务器收到该新选票后会在自己的票箱中更新该服务器的选票。

这一阶段的目的就是为了选出一个准 Leader ，然后进入下一个阶段。

2、发现阶段（Descovery）

在这个阶段，Followers 和上一轮选举出的准 Leader 进行通信，同步 Followers 最近接收的事务 Proposal 。
一个 Follower 只会连接一个 Leader，如果一个 Follower 节点认为另一个 Follower 节点的epoch比自己的小，则会在尝试连接时被拒绝。被拒绝之后，该节点就会进入 Leader Election阶段。

这个阶段的主要目的是发现当前大多数节点接收的最新 Proposal，并且准 Leader 生成新的 epoch ，让 Followers 接收，更新它们的 acceptedEpoch。

3、同步阶段（Synchronization）
 

同步阶段主要是利用 Leader 前一阶段获得的最新 Proposal 历史，同步集群中所有的副本。
只有当 quorum（超过半数的节点） 都同步完成，准 Leader 才会成为真正的 Leader。Follower 只会接收 zxid 比自己 lastZxid 大的 Proposal。

4、广播阶段（Broadcast）

到了这个阶段，Zookeeper 集群才能正式对外提供事务服务，并且 Leader 可以进行消息广播。同时，如果有新的节点加入，还需要对新节点进行同步。
需要注意的是，Zab 提交事务并不像 2PC 一样需要全部 Follower 都 Ack，只需要得到 quorum（超过半数的节点）的Ack 就可以。

到此，崩溃恢复的过程就完成了。