ZAB

ZAB=ZooKeeper Atomic Broadcast

ZooKeeper原子消息广播协议，支持崩溃回复的原子广播协议。

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

1.ZAB保证同一时刻集群中只能够有一个主进程来广播

2.保证一个全局的变更序列被顺序应用。

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

　　所有事物请求必须由一个全局唯一的服务器来协调处理，这样的服务器被称为leader服务器，而余下的其他服务器则成为Follower服务器。leader服务器负责将一个客户端事务请求转化成一个事物

Proposal(提议)，并将该Proposal分发给集群中所有的follower服务器。之后leader服务器需要等待所有follower服务器的反馈。一旦超过半数的Follower服务器进行了正确的反馈后，那么Leader就会再次向所有的Follower服务器分发commit消息，要求将前一个Proposal进行提交。

这里没有paxos的

第一阶段：提议的选定，因为只有leader才能够发起提议。为了防止并发较大的情况下产生活锁。

而第二阶段和第三阶段 accpet和commit和上面的描述比较相近。

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

当整个服务框架在启动过程中，或是当Leader服务器出现网络中断，崩溃退出，与重启等异常情况时，ZAB协议就会进入恢复模式并选举产生新的leader服务器。当选举产生了新的leader服务器，同时集群中已经有过半的机器与该leader服务器完成了状态同步之后。ZAB协议就会退出恢复模式。

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

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

在消息广播过程中，leader服务器会为每一个follower服务器都各自分配一个单独的队列，然后将需要广播的事物proposal依次放入这些队列中去，并且根据FIFO策略进行消息发送。每一个Follower服务器在接收到这个事物Proposal之后，都会首先将其以事务日志的形式写入本地磁盘去。并且在成功写入后反馈给leader服务器一个ack响应。当leader服务器接受到超过半数的follower的ack响应后，就会广播一个commit消息给所有的follower服务器以通知其进行事物提交，同时leader自身也会完成对事务的提交。而每一个follower服务器在接受到commit消息后，也会完成对事务的提交。