深入浅出 Zookeeper 中的 ZAB 协议-技术圈

本文主要内容如下：

ZAB 协议的全称是 Zookeeper Atomic Broadcase，原子广播协议。

作用：通过这个 ZAB 协议可以进行集群间主备节点的数据同步，保证数据的一致性。

在讲解 ZAB 协议之前，我们必须要了解 Zookeeper 的各节点的角色。

Zookeeper 各节点的角色

Leader

负责处理客户端发送的读、写事务请求。这里的事务请求可以理解这个请求具有事务的 ACID 特性。
同步写事务请求给其他节点，且需要保证事务的顺序性。
状态为 LEADING。

Follower

负责处理客户端发送的读请求
转发写事务请求给 Leader。
参与 Leader 的选举。
状态为 FOLLOWING。

Observer

和 Follower 一样，唯一不同的是，不参与 Leader 的选举，且状态为 OBSERING。

可以用来线性扩展读的 QPS。

启动阶段，如何选 Leader？

Zookeeper 刚启动的时候，多个节点需要找出一个 Leader。怎么找呢，就是用投票。

比如集群中有两个节点，A 和 B，原理图如下所示：

节点 A 先投票给自己，投票信息包含节点 id（SID) 和一个 ZXID，如（1,0）。SID 是配置好的，且唯一，ZXID 是唯一的递增编号。
节点 B 先投票给自己，投票信息为（2,0）。
然后节点 A 和 B 将自己的投票信息投票给集群中所有节点。
节点 A 收到节点 B 的投票信息后，检查下节点 B 的状态是否是本轮投票，以及是否是正在选举(LOOKING)的状态。
投票 PK：节点 A 会将自己的投票和别人的投票进行 PK，如果别的节点发过来的 ZXID 较大，则把自己的投票信息更新为别的节点发过来的投票信息，如果 ZXID 相等，则比较 SID。这里节点 A 和节点 B 的 ZXID 相同，SID 的话，节点 B 要大些，所以节点 A 更新投票信息为（2，0），然后将投票信息再次发送出去。而节点 B 不需要更新投票信息，但是下一轮还需要再次将投票发出去。

这个时候节点 A 的投票信息为（2，0），如下图所示：

统计投票：每一轮投票，都会统计每台节点收到的投票信息，判断是否有过半的节点收到了相同的投票信息。节点 A 和节点 B 收到的投票信息都为（2，0），且数量来说，大于一半节点的数量，所以将节点 B 选出来作为 Leader。
更新节点状态：节点 A 作为 Follower，更新状态为 FOLLOWING，节点 B 作为 Leader，更新状态为 LEADING。

运行期间，Leader 宕机了怎么办？

在 Zookeeper 运行期间，Leader 会一直保持为 LEADING 状态，直到 Leader 宕机了，这个时候就要重新选 Leader，而选举过程和启动阶段的选举过程基本一致。

需要注意的点：

剩下的 Follower 进行选举，Observer 不参与选举。
投票信息中的 zxid 用的是本地磁盘日志文件中的。如果这个节点上的 zxid 较大，就会被当选为 Leader。如果 Follower 的 zxid 都相同，则 Follower 的节点 id 较大的会被选为 Leader。

节点之间如何同步数据的？

不同的客户端可以分别连接到主节点或备用节点。

而客户端发送读写请求时是不知道自己连的是Leader 还是 Follower，如果客户端连的是主节点，发送了写请求，那么 Leader 执行 2PC（两阶段提交协议）同步给其他 Follower 和 Observer 就可以了。但是如果客户端连的是 Follower，发送了写请求，那么 Follower 会将写请求转发给 Leader，然后 Leader 再进行 2PC 同步数据给 Follower。

两阶段提交协议：

第一阶段：Leader 先发送 proposal 给 Follower，Follower 发送 ack 响应给 Leader。如果收到的 ack 过半，则进入下一阶段。
第二阶段： Leader 从磁盘日志文件中加载数据到内存中，Leader 发送 commit 消息给 Follower，Follower 加载数据到内存中。

我们来看下 Leader 同步数据的流程：

① 客户端发送写事务请求。
② Leader 收到写请求后，转化为一个 "proposal01：zxid1" 事务请求，存到磁盘日志文件。
③ 发送 proposal 给其他 Follower。
④ Follower 收到 proposal 后，Follower 写磁盘日志文件。

接着我们看下 Follower 收到 Leader 发送的 proposal 事务请求后，怎么处理的：

⑤ Follower 返回 ack 给 Leader。
⑥ Leader 收到超过一半的 ack，进行下一阶段
⑦ Leader 将磁盘中的日志文件的 proposal 加载到 znode 内存数据结构中。
⑧ Leader 发送 commit 消息给所有 Follower 和 Observer。
⑨ Follower 收到 commit 消息后，将磁盘中数据加载到 znode 内存数据结构中。

现在 Leader 和 Follower 的数据都是在内存数据中的，且是一致的，客户端从 Leader 和 Follower 读到的数据都是一致的。

ZAB 的顺序一致性怎么做到的？

Leader 发送 proposal 时，其实会为每个 Follower 创建一个队列，都往各自的队列中发送 proposal。

如下图所示是 Zookeeper 的消息广播流程：

客户端发送了三条写事务请求，对应的 proposal 为

proposal01:zxid1
proposal02:zxid2
proposal03:zxid3

Leader 收到请求后，依次放到队列中，然后 Follower 依次从队列中获取请求，这样就保证了数据的顺序性。

Zookeeper 到底是不是强一致性？

官方定义：顺序一致性。

不保证强一致性，为什么呢？

因为 Leader 再发送 commit 消息给所有 Follower 和 Observer 后，它们并不是同时完成 commit 的。

比如因为网络原因，不同节点收到的 commit 较晚，那么提交的时间也较晚，就会出现多个节点的数据不一致，但是经过短暂的时间后，所有节点都 commit 后，数据就保持同步了。

另外 Zookeeper 支持强一致性，就是手动调用 sync 方法来保证所有节点都 commit 才算成功。

这里有个问题：如果某个节点 commit 失败，那么 Leader 会进行重试吗？如何保证数据的一致性？欢迎讨论。

Leader 宕机数据丢失问题

第一种情况：假设 Leader 已经将消息写入了本地磁盘，但是还没有发送 proposal 给 Follower，这个时候 Leader 宕机了。

那就需要选新的 Leader，新 Leader 发送 proposal 的时候，包含的 zxid 自增规律会发生一次变化：

zxid 的高 32 位自增 1 一次，高 32 位代表 Leader 的版本号。
zxid 的低 32 位自增 1，后续还是继续保持自增长。

当老 Leader 恢复后，会转成 Follower，Leader 发送最新的 proposal 给它时，发现本地磁盘的 proposal 的 zxid 的高 32 位小于新 Leader 发送的 proposal，就丢弃自己的 proposal。

第二种情况：如果 Leader 成功发送了 commit 消息给 Follower，但是所有或者部分 Follower 还没来得及 commit 这个 proposal，也就是加载磁盘中的 proposal 到内存中，这个时候 Leader 宕机了。

那么就需要选出磁盘日志中 zxid 最大的 Follower，如果 zxid 相同，则比较节点 id，节点 id 大的作为 Leader。

本篇尽量用大白话+画图的方式进行讲解，希望能给大家带来启发。如有不足，欢迎留言讨论。

参考资料：

《从Paxos到Zookeeper 分布式一致性原理与实践》

https://time.geekbang.org/column/article/229975