5、Zab协议

一、ZooKeeper协议介绍

zab协议就是zookeeper为了解决分布式一致性自创的一种协议。zab协议主要解决zookeeper 消息同步状态 & 奔溃恢复状态。整个zookeeper集群就在这两个状态之间切换，当leader可用系统出于消息同步状态，当leader挂掉系统出于恢复状态，下面讲讲这两种状态的过程。

二、ZooKeeper节点角色

1、leader-领导者

• 给follower发送心跳
• 处理写请求
• 发起投票
• 负责提交回滚 - 获取半数写成功ack提交事务，否则事务回滚

2、follower-跟随者

• 处理读请求
• 转发写请求
• 参与选举
• 负责同步leader数据

3、observer-观察者

• 负责同步数据
• 处理读请求
• 参与选举但是不直接影响选举结果，observer投票对follower投票有影响

三、ZooKeeper处理写请求流程

1、leader节点，针对当前请求生成事务日志（txn）

2、leader节点，持久化前请求生成事务日志（txn），并向自己发送一个ack

3、leader节点，把当前请求生成的事务日志（txn）发送给其他所有的参与者节点（非observer）

4、leader节点，阻塞等待follower节点发送ack过来（超过一半则解阻塞）

5、follower节点，接收到leader节点发送过来的txn

6、follower节点，持久化当前Txn，并向Leader节点发送一个ack

7、leader节点，接收到了超过一半的ack（加上自己发给自己的ack），则解阻塞

8、leader节点，向follower节点发送commit命令（异步发送的，不会阻塞leader节点）

9、leader节点，执行txn，更新内存（根据txn更新database）

10、follower节点，接收到leader节点发送过来的commit命令

11、follower节点，执行txn，更新内存（根据txn更新database）

 

四、消息同步状态

leader在同步消息过程类似 二阶段提交过程 ，首先leader接收所有写请求，然后发起投票，当半数的follower投票通过，leader提交事务（commit自己、commit follower），否则leader回滚事务。消息同步的时候阻塞在队列中等待一半的follower返回ack，这点不同于raft。

五、奔溃恢复状态

1、奔溃leader状态枚举

1、奔溃前-leader已经提交事务-follower已经全部同步-全部更新 - 不会丢数据

2、奔溃前-leader已经提交事务-follower部分同步-部分更新 - 不会丢数据

3、奔溃前-leader已经提交事务-follower没有同步【不可能落盘后发送ack】-0更新 - 场景不存在

4、奔溃前-leader未提交事务-follower没有同步-0更新 - 不会丢数据

2、奔溃时如何同步数据

1、zxid保证事务全局唯一性

zxid记录每个写事务leader的id和写事务id，其中写事务id递增加1。zk每个节点分为czxid【创建】、uzxid【修改】、pzxid【父节点】。

[zk: localhost:2181(CONNECTED) 3] get /vem
/vem
cZxid = 0x40013f755
ctime = Tue Jun 06 15:51:37 CST 2017
mZxid = 0x19139b86dd
mtime = Tue Nov 09 10:16:14 CST 2021
pZxid = 0x1531b8e72f
cversion = 6
dataVersion = 736
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 4
numChildren = 4

2、奔溃数据恢复

zk崩溃的时候，1场景不需要做数据同步、2场景数据follower数据合并，那么zk如何做到数据合并，其实就是更加zxid的低32位的事务id大小。这样能快速的合并数据。

3、选举leader

半数的follower投票结果选举出leader，observer不参与选举但是对follower的投票结果有影响。然后进行数据恢复。

五、Zab总结

zab协议很多书写的超级复杂，真心看不下去。协议分析要抛弃实现的逻辑单独讨论协议，很多书夹杂太多源码分析了。

• zab 在消息同步状态，通过半数的二阶段提交同步数据，借鉴paxos思想
• zab 在崩溃状态状态，通过半数的follower投片选举leader
• zab 在崩溃状态，通过低32 zxid编码做数据合并