目录

Zookeeper简介

Zab简介

1、Zab角色状态

2、Zab协议中的Zxid

3、Zab流程

3.1、消息广播

3.1.1、消息广播两个阶段

3.1.2、消息广播流程

3.2、崩溃恢复

3.2.1、Zookeeper何时进入崩溃恢复阶段

3.2.2、Leader选举过程

3.3、数据同步

4、Zab与Paxos算法的联系与区别

Zookeeper简介

  • Zookeeper应用:数据发布与订阅、命名服务、配置中心、注册中心、分布式锁。
  • ZooKeeper 提供一个类似于 Linux 文件系统的数据模型,和基于 Watcher 机制的分布式事件通知,这些特性都依赖 ZooKeeper 的高容错数据一致性协议(Zab)。
  • Zookeeper集群中,所有客户端请求都会发给Leader节点,然后Leader节点将数据同步到其他Follower节点。集群数据同步过程中,如果Leader或Follower节点崩溃,则会通过Zab协议来保证Zookeeper的数据一致性。

Zab简介

Zab,ZooKeeper Atomic Broadcast,ZooKeeper 原子广播协议,支持消息广播崩溃恢复,通过实现一种主备模式的系统架构来保持集群中各个副本之间的一致性。

1、Zab角色状态

        主节点状态Leader,从节点状态Follower,选举状态looking。

zookeeper 保证消息有序 zookeeper怎么保证一致性_分布式

2、Zab协议中的Zxid

        事务编号,是一个64位数字:低 32 位是一个简单的单调递增计数器,针对客户端每一个事务请求,计数器加 1;而高 32 位则代表 Leader 周期(epoch)年代的编号。

        周期epoch可以类比为Raft算法中的任期(Term),可以理解为当前集群所处的年代或者周期,每一次Leader选举都会开始一个新的任期,保证在给定一个任期,最多只有一个Leader。

        每当有一个新的 Leader 选举出现时,就会从这个 Leader 服务器上取出其本地日志中最大事务的 Zxid,并从中读取 epoch 值,然后加 1,以此作为新的周期 ID。

        高 32 位代表了每代 Leader 的唯一性,低 32 位则代表了每代 Leader 中事务的唯一性。

3、Zab流程

zookeeper 保证消息有序 zookeeper怎么保证一致性_zookeeper 保证消息有序_02

3.1、消息广播

解决Follower节点崩溃的情况

3.1.1、消息广播两个阶段:

  • 广播事务:ZooKeeper中所有的事务请求都由 Leader 节点来处理,Leader 将客户端的事务请求转换为事务 Proposal,并将 Proposal 分发给集群中其他所有的 Follower。
  • 广播提交:完成广播之后,Leader 等待 Follwer 反馈,当有过半数(节点数 >=N/2+1)的 Follower 反馈信息后,Leader 将再次向集群内 Follower 广播 Commit 信息。Follower收到Commit信息后,就会将之前收到的Proposal提交。

3.1.2、消息广播流程:

  1. 客户端的写请求进来之后,Leader 会将写请求包装成 Proposal 事务,并添加一个递增事务 ID,也就是 Zxid,Zxid 是单调递增的,以保证每个消息的先后顺序;
  2. 广播这个 Proposal 事务,Leader 节点和 Follower 节点是解耦的,通信都会经过一个先进先出的消息队列,Leader 会为每一个 Follower 服务器分配一个单独的 FIFO 队列,然后把 Proposal 放到队列中;
  3. Follower 节点收到对应的 Proposal 之后会把它持久到磁盘上,当完全写入之后,发一个 ACK
  4. 当 Leader 收到超过半数 Follower 机器的 ack 之后,会提交本地机器上的事务,同时开始广播 commit, Follower 收到 commit 之后,完成各自的事务提交。

3.2、崩溃恢复

        解决Leader节点崩溃的情况

        保证在 Leader 进程崩溃的时候可以重新选出 Leader,并且保证数据的完整性。

        崩溃恢复模式将会开启新的一轮选举,选举产生的 Leader 会与过半的 Follower 进行同步,使数据一致,当与过半的机器同步完成后,就退出恢复模式, 然后进入消息广播模式。

3.2.1、Zookeeper何时进入崩溃恢复阶段

  • 初始化集群,刚刚启动的时候
  • Leader 崩溃,因为故障宕机
  • Leader 失去了半数的机器支持,与集群中超过一半的节点断连

3.2.2、Leader选举过程

  • 各个节点变更状态,变更为 Looking
  • 各个 Server 节点都会发出一个投票,参与选举

        在第一次投票中,所有的 Server 都会投自己,然后各自将投票发送给集群中所有机器,在运行期间,每个服务器上的 Zxid 大概率不同。

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

        处理投票的过程就是对比 Zxid 的过程。

                a、首先选举 epoch 最大的

                b、如果 epoch 相等,则选 zxid 最大的

                c、若 epoch 和 zxid 都相等,则选择 server id 最大的,就是配置 zoo.cfg 中的 myid

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

  • 选举成功,改变服务器的状态

3.3、数据同步

        在选举过程中,通过投票已经确认 Leader 服务器是最大Zxid 的节点,同步阶段就是利用 Leader 前一阶段获得的最新Proposal历史,同步集群中所有的副本。

4、Zab与Paxos算法的联系与区别

  • Paxos 是理论,Zab 是基于Paxos的实践。
  • Paxos 是论文性质的,目的是设计一种通用的分布式一致性算法,而 Zab 协议应用在 ZooKeeper 中,是一个特别设计的崩溃可恢复的原子消息广播算法。