ZooKeeper_16_ZAB协议_很重要

ZooKeeper的ZAB一致性协议

别被这个"ZAB协议"的名字所迷惑，这玩意的实现作用其实是ZooKeeper的事务，对了解ZooKeeper蛮重要的..

本文理论性文字较多，但个人感觉很重要...需要静下心来，好好看看，或者去看原书

在《从PAXOS到ZOOKEEPER分布式一致性原理与实践》书中，ZAB协议是放在前面讲的，不过我个人觉得，放在后面看好一些，

因为一大段的理论内容，肯定会让不少人反感，而且在使用zk的时候肯定有不少疑问，会随着这一章，有所了解，带着问题看书..

一致性协议

我们先大致了解下什么是"一致性协议"

在对一个分布式系统进行架构设计的过程中，往往会在系统的可用性和数据一致性之间进行反复的权衡，于是产生了一系列的一致性协议。

其中最著名的是：二阶段提交协议、三阶段提交协议、Paxos算法

综上，"一致性协议"的作用就是用来解决系统可用性和数据一致性之间的问题

ZooKeeper的ZAB协议

ZooKeeper使用ZooKeeper Atomic Broadcast(ZAB，ZooKeeper原子消息广播协议)的协议作为其数据一致性的核心算法。

在ZooKeeper中主要依赖ZAB协议来实现分布式数据一致性，基于该协议，ZooKeeper实现了一种主备模式的系统架构来保持集群中各副本之间数据的一致性。

讲的具体些：

ZooKeeper使用一个单一的主进程来接收并处理客户端的所有事务请求，并采用ZAB的原子广播协议，将服务器数据的状态变更以事务Proposal的形式广播到所有的副本进程上去。

ZAB协议的核心是定义了对于那些会改变ZooKeeper服务器数据状态的事务请求的处理，即：

所有事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器被称作Leader服务器。余下的其他服务器则是Follower服务器。

Leader服务器负责将一个客户端事务请求转换成一个事务Proposal(提议)，并将该Proposal分发给集群中所有的Follower服务器。

之后Leader服务器需要等待所有Follower服务器的反馈，一旦超过半数的Follower服务器进行了正确的反馈之后，
那么Leader就会再次向所有的Follower服务器分发Commit消息，要求它们将前一个Proposal进行提交。

协议介绍

ZAB协议包括两种基本模式：崩溃恢复、消息广播

当整个服务框架再启动过程中，或是当Leader服务器出现网络中断、崩溃退出、重启等异常情况时，ZAB协议就会进入崩溃恢复模式，并选举新的Leader服务器。

当选举产生了新的Leader服务器，同时集群中已经有过半的机器与该Leader服务器完成了状态同步之后，ZAB协议就会退出崩溃恢复模式。

(所谓的状态同步是指数据同步，用来保证集群中存在过半的机器能和Leader服务器的数据状态保持一致)

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

当一台同样遵守ZAB协议的服务器启动后加入到集群中时，如果此时集群中已经存在一个Leader服务器，并正在进行消息广播，

那么新加入的服务器就会自觉地进入到数据恢复模式：找到leader服务器，与其进行数据同步，然后一起参与到消息广播中去。

ZooKeeper设计成只允许唯一一个Leader服务器来进行事务请求的处理。

Leader服务器在接收到客户端的事务请求后，会生成对应的事务提案并发起一轮广播协议；

而如果集群中的其他机器接收到客户端的事务请求，那么这些非Leader服务器会首先将这个事务转发给Leader服务器。

消息广播

ZAB协议的消息广播过程使用的是一个原子广播协议，类似于一个二阶段提交过程。

针对客户端的事务请求，Leader服务器会为其生成对应的事务Proposal，并将其发送给集群中其余的机器，然后再分别收集各自的选票，最后进行事务提交。

在ZAB协议的二阶段提交过程中，所有的Follower服务器要么正常反馈Leader提出的事务Proposal，要么就抛弃Leader服务器。

在整个消息广播过程中，Leader服务器会为每个事务请求生成对应的Proposal来进行广播，并且在广播事务Proposal之前，

Leader服务器会首先为这个事务Proposal分配一个全局单调递增的唯一ID，我们称之为事务ID(即ZXID)。

由于ZAB协议需要保证每一个消息严格的因果关系，因此必须将每一个事务Proposal按照其ZXID的先后顺序来进行排序与处理。

讲的具体一些：

a. 在消息广播过程中，Leader服务器会为每个一个Follower服务器都各分配一个单独的队列

b. 然后将需要广播的事务Proposal依次放入这些队列中去，并且根据FIFO策略进行消息发送。

c. 每一个Follower服务器在收到这个事务Proposal之后，都会首先将其以事务日志的形式写入到磁盘中去，并且在成功写入后反馈给Leader服务器一个ACK响应。

d. 当Leader服务器接收到超过半数Follower的ACK响应之后，就会广播一个Commit消息给所有的Follower服务器以通知其进行事务提交，同时Leader服务器自身也会完成对事

务的提交，而每一个Follower服务器在接收到Commit消息后，也会完成对事务的提交。

崩溃恢复

ZAB协议的这个机遇原子广播协议的消息广播过程，在正常情况下运行良好，但是一旦Leader服务器出现崩溃，

或者说由于网络原因导致Leader服务器与过半Follower服务器失去联系，那么就会进入崩溃恢复模式。

基本特性

ZAB协议规定了如果一个事务Proposal在一台机器上被处理成功，那么应该在所有的机器上都处理成功，哪怕机器出现故障崩溃。

a. ZAB协议需要确保那些已经在Leader服务器上提交的事务最终被所有服务器都提交

假如一个事务在Leader服务器上被提交了，并且已经得到过半Follower服务器的ACK反馈，

但是在他将Commit消息发送给所有Follower机器之前，Leader服务器挂了..╮(╯▽╰)╭

(借用书上的原图)

集群运行正常的某个时刻，Server1(leader)服务器，先后广播P1,P2,C1,P3,C2消息。

当leader服务器将C2消息发出后立即就奔溃退出了。

针对这种情况，ZAB协议就需要确保事务Proposal2最终能够在所有的服务器上都被提交成功，否则将会出现不一致。

b. ZAB协议需要确保丢弃那些只在Leader服务器上被提出的事务

如果在崩溃恢复过程中出现一个需要被丢弃的提案，那么在崩溃恢复结束后需要跳过该事务Proposal。

(借用书上的原图)

Leaer服务器Server1提出一个事务P3，之后立马就挂，退出集群，从而导致集群中其他的机器都没有收到这个事务请求。

于是当Server1恢复过来，再次加入到集群中的时候，ZAB协议需要能确保丢弃P3这个事务。

综合上面两个崩溃恢复过程中需要处理的特殊情况，就决定了ZAB协议必须设计这样Leader选举算法：

能确保提交已经被Leader提交的事务Proposal，同时丢弃被跳过的事务Proposal

针对这个要求：

让Leader选举算法能够保证新选举出来的Leader服务器拥有集群中所有机器最高编号(ZXID最大)的事务Proposal，

就可以保证这个新选举出来的Leader一定具有所有已经提交的提案。

更为重要的是，如果让具有最高编号事务Proposal的机器来成为Leader，就可以省去Leader服务器检查Proposa的提交和丢弃工作这一步

--------------------------------------------------------------------------------------------------------------------------

之前还没看ZAB的时候，有下面这个疑问，现在看完ZAB之后，就明白了...筋骨也好了，爬六楼，都不带喘气的...

当时的疑问：

客户端连接zk集群中的任何一台服务器，发送创建节点请求；

假设这个服务器是follower，然后这个follower服务器将请求发送给leader服务器，由leader进行操作，然后同步给集群中的其他角色机器..

如果上面说的没问题，那么问题来了..

按照上面的说法，全部由leader同步给其他角色机器，那么也就是说，集群中所有机器的事务ID(ZXID)都是一样的...

好，既然ZXID事务ID都是一样的，那么leader选举的时候，为什么要用这个参数呢？？

你现在是否明白了呢？