Zookeeper的ZAB协议原理详解

最新推荐文章于 2024-05-16 22:54:28 发布

李君临

最新推荐文章于 2024-05-16 22:54:28 发布

阅读量1.6k

点赞数 24

文章标签： zookeeper 分布式 zab

本文链接：https://blog.csdn.net/qq_33472553/article/details/136791138

版权

Zookeeper的ZAB协议原理详解

如何保证数据一致性。

Paxos，

吸收了主从。

zk = 数据模型+Watch机制

zab zookeeper原子广播协议。

ZAB概念

ZooKeeper是通过Zab协议来保证分布式事务的最终一致性。

Zab(ZooKeeper Atomic Broadcast,.ZooKeeper原子广播协议)支持崩溃恢复，基于该协议，ZooKeeper实现了一种主备模式的系统架构来保持集群中各个副本之间数据一致性。

在这里插入图片描述

在ZooKeeper集群中，所有客户端的请求都是写入到Leader进程中的，然后，由Leader同步到其他节点，称为Follower.。在集群数据同步的过程中，如果出现Follower节点崩溃或者Leader进程崩溃时，都会通过Zab协议来保证数据一致性。
Zab协议的具体实现可以分为以下两部分：

消息广播阶段
- 大部分时期的模式，正常工作模式
- 数据同步问题
- Leader负责处理客户端的写入操作，接受事务提交，每次接受一个事务的时候就会产生一个提案对象(Proposal)请求广播给
  Follower,Leader收集各个节点的反馈，然后在决定是否Commit(提交事务，真正写入zk)。
崩溃恢复阶段
- 不能对外提供功能，CP
- 选举问题
- 比如Leader宕机，会进入到崩溃恢复节点，重新进行选举，崩溃恢复阶段还包括数据同步的操作，同步集群中最新的数据，保持集群一
  致性
- 一般情况下，数据最新的会当选为主节点
当Leader可用时，正常的消息广播阶段
当Leader不可用时，进入到崩溃恢复阶段，选举完成新的Leader)后会进行数据同步，当数据同步完成以后，此时才会重新进入到消息广播阶
段。

事务编号ZXid

ZXid(64位) = epoch（年代） + 递增器 32

Zxid是Zb协议的一个事务编号，Zxd是一个64位的数字，其中低32位是一个简单的单调递增计数器，针对客户端每一个事务请求，计数器
加1；而高32位则代表Leader周期年代(Epoch)的编号。

周期年代的概念和Raft中Term(任期)概念是一样的。

在这里插入图片描述

每次有一个新的Leader选举出现时候，Leader服务器取出本地日志中最大的事务ZXID,读取epoch值，进行+1操作，作为新的周期ID。

ZAB流程分析

ZAB流程可以拆分为：消息广播–>崩溃恢复–>数据同步

消息广播

在ZooKeeper中所有的事务请求都由Leader节点来处理，其他服务器为Follower,Leader将客户端的事务请求转换为事务Proposal,并且将Proposal分发给集群中其他所有的Follower。
完成广播之后，Leader等待Follwer反馈，当有过半数的Follower反馈信息后，Leader就commit，将再次向集群内Follower广播Commit信息，Commit信息就是确认将之前的Proposal提交。

Acknowledge 承认

ACK （Acknowledge character）即是确认字符

在这里插入图片描述

崩溃恢复

下面的几种情况都会进入崩溃恢复阶段：

初始化集群，刚刚启动的时候，无主
Leader崩溃，因为故障宕机
Leader失去了半数的机器支持，与集群中超过一半的节点断连，比如：发生了网络分区

崩溃恢复模式会开启新一轮的选举，选举产生的Leader会与过半的Follower进行数据同步，使数据一致，推出崩溃恢复模式，进入到消息广播模式。

状态	说明
Following	当前节点是跟随者，服从Leader节点的命令
Leading	当前节点是Leader,负责协调事务
Election/Looking	节点处于选举状态

崩溃恢复案例

在这里插入图片描述

server2 Leader节点挂了

1.各个节点变更状态，变更为Looking

Leader、Follower、Observer,Observer不参数与选举
Leader挂了，Follower都会将自己的状态改为Looking:状态，开始进入Leader选举过程。

2.各个Server节点都会发出一个投票，参与选举

第一次投票，每个Sevr都会投自己一票，发送给集群中的所有机器
在运行期间并不是所有Server的ZXID都是一致的（事务引D,越大数据版本越新，数据越完整）

3.集群接收来自各个服务器的投票，开始处理投票和选举

处理选票的过程其实就是对比ZXID的过程，假设3号Server的ZXID最大，比如Server1收到Server3的选票，发现Server:3比自己的Zxid要
大，Server1就投票给Server3。
首先会判断Epoch(Term任期)
如果Epoch相等，则选择ZXID最大。
加入Epoch相等，ZXID也一样的，zoo.cfg中为了区分每个服务器，都会给服务器一个编号，myid。此时就对比myid。

在选举过程中，如果有节点获得超过半数的投票数，则会成为Leader节点，反之则重新投票选举。

在这里插入图片描述