Zookeeper_ZAB协议

ZAB协议

ZAB协议简介

ZAB：（Zookeeper Atomic Broadcast），zk原子消息广播协议，是专为ZK设计的一中支持崩溃恢复的原子广播协议，是一种Paxos协议的优化算法，在ZK中，主要依赖ZAB协议来实现分布式数据的一致性

ZK使用一个单一主进程来接受并处理客户端的所有事务请求，即写请求，当服务器数据的状态发射管变更时，集群采用ZAB原子广播协议，以事务提案Proposal的形式广播道所有的副本进程上，ZAB协议能够保证一个全局的变更序列，即可以为每一个事务分配一个全局的递增编号Xid.

当ZK客户端连接到ZK集群的任意节点后，若客户端提交的读请求，那么当前节点就直接根据自己保存的数据对其进行响应，如果是写请求且当前节点不是Leader，那么节点就会将该写请求请求转发给Leader,Leader会以提案的方式广播该写操作，只要超过半数节点同意该写操作，则该写操作请求就会被提交，然后Leader会再次广播给所有的Learner,通知他们同步数据

集群中的三种角色

为了避免ZK的单点问题，ZK也是以集群的形式出现的，ZK集群中的角色主要有以下三类

Leader：

集群写请求的唯一处理者，并负责进行投票的发起和决议，更新系统状态，Leader是很明主的，在接受到一个一个写请求的时候，会以广播的方式提出一个提议，在大多数zkServer均同意的情况下才会作出修改

Follower：

接受客户端的请求，处理读请求时，直接响应结果，如果是写请求的话，则是需要转发给Leader处理；

在选举Leader的过程中参与投票；

Observer：

可以看作是无选主投票权、写操作投票权的Follower，他都不会计算在集群的服务机器台数中，主要的作用是为了协助Follower处理更多的读请求，当我们ZK的读请求的负载很高时，势必要添加Follower身份的机器加入集群，这样集群中的机器数量就会变得居多，拖慢写操作的效率(机子越多通信压力就越大，Leader的选举，写操作的投票都更耗时)，这个时候我们选择添加Observer服务器，既可以提高处理读请求的吞吐量，集群机器数量又没有增加，岂不是美滋滋！

ZK服务的三种状态

ZAB协议中对zkServer的状态描述为三种模式：恢复模式、同步模式、广播模式

恢复模式：

在服务重启过程中，或者Leader崩溃后，就会进入到恢复模式，要恢复到ZK集群正常的工作状态

同步模式：

在所有的zkServer启动完毕或者Leader崩溃后又选举出来了新的的Leader,就会进入到同步模式，各个Follower需要马上将Leader中的数据同步到自己的主机中，当完成数据同步后，同步模式旋盖结束，同步模式被包含在恢复模式中

广播模式：

当Leader的提议被大多数zkServer同意后，Leader会修改自身数据，然后会将修改后的数据广播给其他的Follower

zxid

zxid为64位长度的Long类型，其中高32位表示纪元epoch，低32位表示事务标识xid；
每一个Leader都会具有一个不同的epoch值，表示一个时代，每一次新的选举开启是都会生成一个新的epoch，新的Leader产生，则会更新所有zkServer的zxid中的epoch
xid则为ZK的事务id,每一个写操作都是一个事务，都会有一个xid,xid为一个依次递增的流水号，每一个写操作都需要由Leader发起一个提案，由所有的follower表决死都同意本次写操作，而每一个提案都具有一个xid

消息广播算法

当集群中已经有过半的Follower与Leader服务器完成了状态同步，那么整个ZK集群就可以进入到消息广播模式了

无非就是，如果来了一个写请求，受理的节点不是LEader,就会请求转发给Leader，Leader会为其生成对应的全局唯一的64位自增zxid，通过zxid的大小比较，即可实现事务的有序性管理，

为了保证Leader向Follower发送提案的有序性，，Leader会为每一个Follower创建一个FIFO队列，并将提案写入到该队列中，然后通过队列发送给Follower

当Follower接受到提案后，会先将提案的zxid与本地记录的的事务日志中最大的zxid进行比较，若提案中的zxid更大，则将该zxid记录到本地进行覆盖，然后响应Leader一个ACK回执

当Leader收到过半的ACK回执后,Leader就会向所有的Follower发送Commit消息，批准各个Follower在本地执行该消息，当Follower收到Commit消息后，就会执行事务提交，至于那些没有响应回执的，Leader直接发对应的提案和一个Commit提交过去，直接完成数据的事务提交

恢复模式的两个原则

当集群正在启动过程中，或者Leader与超过半数的主机断连后，集群就会进入到恢复模式，对于要恢复的数据状态需要遵循两个原则

第一个：已经被处理的消息不能丢

当Leader收到超过半数的Follower的ACK回执后，就会向各个Follower广播Commit消息，各个服务都在本地执行写操作并完成事务提交，然后就会向客户端响应写操作成功，但是如果在非全部的Follower收到Commit之前Leader就挂掉了，这就会导致一部分server没有收到事务提交请求，从而没有完成数据的写入，最后集群中的机器中的数据不一致了，下面又要选取新的Leader了，ZK肯定不允许那些没有收到Commit请求的机器当选，因为他们的本地数据不完整，为了保证"已经被处理的消息不能丢"，ZAB的恢复模式使用下面的这种策略

选举拥有proposal最大值(即zxid最大)的节点作为新的Leader,zxid最大的节点的数据肯定是最完整的

新的Leader先将自身拥有的zxid，发送给所有的Follower,然后将这些zxid的commit命令发送给所有的Follower,保证所有的Follower都保存并执行了所有的zxid所对应的事务提交，这样就会造成被处理过的消息不会丢失