zookeeper的zab协议工作原理之原子广播

说zab协议之前必须提一下 paxos 协议 

paxos协议主要就是如何保证在分布式环网络环境下，各个服务器如何达成一致最终保证数据的一致性问题

ZAB协议，基于paxos协议的一个改进。

zab协议为分布式协调服务zookeeper专门设计的一种支持崩溃恢复的原子广播协议

zookeeper并没有完全采用paxos算法， 而是采用zab Zookeeper atomic broadcast

 

zab协议的原理

1. 在zookeeper 的主备模式下，通过zab协议来保证集群中各个副本数据的一致性

2. zookeeper使用的是单一的主进程来接收并处理所有的事务请求，并采用zab协议，

把数据的状态变更以事务请求的形式广播到其他的节点

3. zab协议在主备模型架构中，保证了同一时刻只能有一个主进程来广播服务器的状态变更

4. 所有的事务请求必须由全局唯一的服务器来协调处理，这个的服务器叫leader，其他的叫follower

leader节点主要负责把客户端的事务请求转化成一个事务提议（proposal），并分发给集群中的所有follower节点

再等待所有follower节点的反馈。一旦超过半数服务器进行了正确的反馈，那么leader就会commit这条消息。

5.然后再进行leader 和 follower 直接的数据同步。

这里有几个地方要注意一下：

1、follower服务器的投票并不是真正意义上的投票，而是follower 服务器 表示收到了 leader节点发过来的消息，给予一个收到的提示。 跟分布式事务中的 两阶段提交 中的第一阶段类似。

2、zab协议 与 分布式事务不同的是， 分布式事务 的两阶段提交要求所有事务处理节点（器）都要投票同意。

    而zab协议中 只要求半数 服务器节点投票同意即可。

    为什么只要半数就可以了呢？是因为zab协议就是为了保证在网络不可靠的情况下，整个集群还能正常的工作。

    有超过半数的服务器投票同意，那么leader节点就执行写的操作，commit之后，再进行原子广播给其它的follower节点， 让 follower节点来同步数据

    如果跟两阶段提交一样，还需要所有节点都同意的话，那明显与zab协议的使用场景不同了。

图的流程大致是：

1、客户端发来一个request给第一个follower节点，如果是读请求，follower节点直接将数据返回。

2、如果是写请求，也就是事务请求，那么follower节点就将请求转发给leader，leader再像集群中的 follower节点发起一个事务请求提议（proposal）。

3、follower节点正常情况下 都会返回一个ack 给 leader ，表示 follower 节点收到 leader的消息了，这里就是所谓的投票。

    正常情况下都会投票的，没有投票的情况就是 有的follower 节点 挂掉了 投不了票就没投。

3、当机器中超过半数的服务器 都投票了（leader 自己本身也参与投票），那么 leader就commit 这个事务请求，然后再通过原子广播 通知 集群中其它的 follower 跟 Ob 节点来同步数据。