ZooKeeper一致性协议ZAB学习笔记

一、ZAB 协议介绍

ZAB 协议全称：Zookeeper Atomic Broadcast（Zookeeper 原子广播协议）。ZAB协议是为分布式协调服务Zookeeper专门设计的一种支持崩溃恢复和原子广播的协议。全部客户端写入数据都是写入到 主进程（称为 Leader）中，而后，由 Leader 复制到备份进程（称为 Follower）中，从而保证数据一致性。ZAB 只须要 Follower 有一半以上返回 Ack 信息就能够执行提交，大大减少了同步阻塞，也提升了可用性。当 Leader 服务能够正常使用，就进入消息广播模式，当 Leader 不可用时，则进入崩溃恢复模式。

二、消息广播

ZAB 协议的消息广播过程使用的是一个原子广播协议，对于客户端发送的写请求，所有由 Leader 接收，Leader 将请求封装成一个事务，将其发送给全部 Follwer ，而后，根据全部 Follwer 的反馈，若是超过半数成功响应，则执行 commit 操做。

三、崩溃恢复

当 Leader 崩溃，即Leader 失去与过半 Follwer 的联系。可能会出现两种状况

Leader 在复制数据给全部 Follwer 以后崩溃，怎么办？

Leader 在收到 Ack 并提交了本身，同时发送了部分 commit 出去以后崩溃怎么办？

ZAB 定义了 2 个原则：可以确保提交已经被 Leader 提交的事务，同时丢弃已经被跳过的事务。

Leader 选举算法可以保证新选举出来的 Leader 服务器拥有集群总全部机器编号（即 ZXID 最大）的事务，那么就可以保证这个新选举出来的 Leader 必定具备全部已经提交的提案。

四、数据同步

当崩溃恢复以后，须要在正式工做以前（接收客户端请求），Leader 服务器首先确认事务是否都已经被过半的 Follwer 提交了，便是否完成了数据同步。目的是为了保持数据一致。

当全部的 Follwer 服务器都成功同步以后，Leader 会将这些服务器加入到可用服务器列表中。

在 ZAB 协议的事务编号 ZXID 设计中，ZXID 是一个 64 位的数字，其中低 32 位能够看做是一个简单的递增的计数器，针对客户端的每个事务请求，Leader 都会产生一个新的事务 Proposal 并对该计数器进行 + 1 操做。

而高 32 位则表明了 Leader 服务器上取出本地日志中最大事务 Proposal 的 ZXID，并从该 ZXID 中解析出对应的 epoch 值，而后再对这个值加一。

当 Follower 连接上 Leader 以后，Leader 服务器会根据本身服务器上最后被提交的 ZXID 和 Follower 上的 ZXID 进行比对，比对结果要么回滚，要么和 Leader 同步。