Fast Paxos的工业实现-ZAB(上)

Posted 2021-04-17 java日常笔记

在上一篇文章中，主要介绍了Paxos算法，，文章中提到了"每个提议者在提出提案时都会首先获取到一个具有全局唯一性的、递增的提案编号N"，但是在实际应用中对该N值得操作有可能出现活锁问题。本文将着重介绍下Paxos算法的缺陷以及Fast Paxos的工业实现ZAB。

Paxos的活锁问题

paxos算法在实际工程应用过程中，根据不同的实际需求存在诸多不便之处，所以也就出现了很多对于基本Paxos算法的优化算法，以对Paxos算法进行改进，例如，Multi Paxos、Fast Paxos 、Epaxos。
例如：Paxos算法存在"活锁问题",Fast Paxos 算法对Paxos 算法进行了改进，其只允许一个进程处理写请求，解决了活锁问题。

活锁与死锁

此处有必要介绍下活锁与死锁。

死锁:是指两个或两个以上的进程（或线程）在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。
举例：
1、两个房间得钥匙都在对方的屋子当中。
2、哲学家进餐问题.一张桌子三个哲学家，小抠1、小抠2和小抠3，每个人就分了一根筷子。

死锁具备的条件：

• 互斥：一个资源只能被一个进程使用---一根筷子只能被一个人使用。

• 请求与保持：一个进程因为请求资源被阻塞，对获得的资源又保持不放---"你不给我要筷子，我也不给你"

• 不剥夺：我拿到一个资源，你不能给我抢走了---"你不能耍流氓，把我的筷子抢走"

• 循环等待：线程a等待b，b等待c，c等待a---"小抠1等待小抠2的筷子，小抠2等待小抠3的筷子"
  这四个条件打破一个，死锁问题就解决了。

活锁：任务或者执行者没有被阻塞，由于某些条件没有满足，导致一直重复尝试，失败，尝试，失败。
举例：小A有两块糖，张三、李四、王五分别来抢，倒霉的张三一直尝试就是抢不到，失败，尝试，失败。

活锁和死锁的区别在于，处于活锁的实体是在不断的改变状态，所谓的“活”， 而处于死锁的实体表现为等待；活锁有可能自行解开，死锁则不能。

Paxos为什么会产生活锁呢？

Paxos算法中每个进程均可提交提案，但必须要获取到一个全局的唯一编号N，将该N值赋予提案。为了保证N的唯一性，对该N值的操作就必须要放到同步锁(排他锁)中，即，N值就成为了"竞争资源"。若一个进程为了提交提案，一直在不停的申请资源N，但是如果这个进程特别点背，每一次都没有分配给它，此时的该进程就处于"活锁"状态。
有问题就有解决的方法，Fast Paxos算法出现了，它只允许一个进程提交提案，即其具有对N的唯一操作权。该方式解决了"活锁"问题，下面要介绍得ZAB就是Fast Paxos得工业实现。

ZAB协议

ZAB协议简介

ZAB协议是Fast Paxos 算法得一种工业实现算法。
ZAB，Zookeeper Atomic Broadcast，Zookeeper原子消息广播协议，是转为Zookeeper 设计的一种支持崩溃恢复的原子广播协议，在Zookeeper中，主要依赖ZAB协议来实现分布式数据一致性。
当Zookeeper客户端连接到Zookeeper 集群中的一个节点后，若客户端提交的是读请求，那么当前节点就直接根据自己保存的数据对其进行响应，如果是写请求且当前节点不是Leader，那么节点就会将该写请求转发给Leader，Leader会以提案的方式广播该写操作，只要有超过半数节点同意该写操作，则该写操作请求就会被提交，然后Leader 会再次广播给所有订阅者，即Learner ，通知他们同步数据，详见下图：

三类角色

在实际生产中为了避免Zookeeper的单点问题，Zookeeper也是以集群的方式存在的，Zookeeper集群中的角色主要有以下三类：

• Leader:Zookeeper集群写请求的唯一处理者，并负责进行投票的发起和决议，更新系统状态。

• Follower:接收客户端请求，处理读请求，并向客户端返回结果，将写请求转给Leader；在选Leader过程中参与投票。

• Observer:可以理解为阉割版的Follower ，没有选Leader的权利，也没有写操作投票权，其不属于法定人数范围，主要是为了而协助Follower处理更多的读请求。

三种模式

ZAB协议中对zkServer的状态描述有三种模式:恢复模式、同步模式和广播模式，这三种模式并没有十分明显的界限，它们相互交织在一起。

• 恢复模式：在服务重启过程中，或在Leader崩溃后，就进入了恢复模式，恢复模式主要包含两个阶段；Leader的选举阶段与初始化同步阶段，这两个阶段完成后Zookeeper集群恢复到正常服务状态。

• 广播模式(对于Leader而言)：广播模式分为两类，初始化广播与更新广播。当Leader被选举出来后，Leader需要将自己拥有但其它Server可能没有的事务及自己的epoch广播给所有的Learner，这是初始化广播。在集群正常服务时，当Leader的事务提案被大多数Follower同意后，Leader会修改自身数据，然后会将修改后的数据广播给其它Learner，这是更新广播。

• 同步模式(对于Learner而言)：与广播模式相对应，同步模式也分为两类，初始化同步及更新同步，当Leader 选举出来并发布过其初始化广播后，所有Learner 需要将Leader 广播的事务及epoch 同步到本地，这称为初始化同步，在集群正常服务时，当Leader发布了更新广播后，Learner 需要将Leader 广播的事务同步到本地，这称为更新同步。

三个数据

在Zookeeper 中有三个很重要的数据：zxid 、epoch 与 xid
zxid为64位长度的Long类型，其中高32位表示纪元epoch，低32位表示事务标识xid，即zxid由两部分构成：epoch 与 xid。
每个Leader都会具有一个不同的 epoch值，表示一个时期、时代。每一次新的选举结束后都会生成一个新的epoch（理解为"我是新的leader，这是我时代"） ，新的Leader产生，则会更新所有zkServer的zxid中的epoch。
xid则为Zookeeper 的事务id，每一个写操作都是一个事务，都会有一个xid。xid为一个依次递增的流水号。每一个写操作都需要由Leader发起一个提案，由所有Follower 表决是否同意本次写操作，而每个提案都具有一个 zxid。

总结：

本文主要介绍了。Paxos的缺陷，以及Fast Paxos的工业实现ZAB,并简要介绍了提交一个写操作经历的流程，以及Zookeeper集群中的三种模式和三种角色以及三个数据都是什么，对于ZAB并没有介绍完全，下一篇文章中，将会详细介绍当Leader挂掉以后，集群中是怎么选新领导的，集群中又是怎么同步新领导思想的。