分布式理论：ZAB协议

一、简介

前面的博文介绍了2pc、3pc以及paxos，到了具体的工程实现中，分布式协议的实现并没有那么简单，很多时候需要做出一些取舍，下面介绍zookeeper的分布式一致性协议ZAB（ZooKeeper Atomic Broadcast ZooKeeper原子消息广播协议）。

ZAB的核心处理方式

所有事务请求必须由一个全局唯一的服务器来协调处理，这个服务器成为leader，其他称为follower,leader负责将一个客户端事务请求转换成一个事务Proposal,并将该Proposal分发给集群中所有Follower,一旦超过半数返回正确，leader就会给Follower发Commit,要求提交前一个proposal。

ZAB的两种工作模式简述

崩溃恢复

当整个服务框架启动或者是leader宕机时，会进入崩溃恢复模式。

消息广播

当选举出新的leader，同时集群中有过半的机器与leader服务器完成状态同步（这里是指过半的机器和leader数据保持一致），这时整个框架进入消息广播模式。

如果这个时候一台新的机器加入集群，会自觉进入数据恢复模式：

首先会找到leader服务器与其进行同步

参与到消息广播中

当leader宕机或者下面的机器少于一半回复，就需要选取新的leader，下面详细介绍一下这两种工作模式流程。

二、两种工作模式简述

消息广播

消息广播类似于之前的一篇博文2pc方式提交，忘了的可以回忆一下

（/article/9415559.html）：由leader提出一个决议，然后发送给集群中的其他机器，收集所有选票，最后进行提交。但是这里和2pc有一些区别，2PC是强一致，一旦接受到一个NO，则该事务失败，进行中断。ZAB这里只要有一半的follower服务器反馈了ACK就能提交事务，不需要等待所有的执行完成。当然，一旦这个过程中leader崩溃，就会出现数据不一致。

所以ZAB协议中添加了另一个模式，采用崩溃恢复模式。由于协议是用TCP协议进行通信，所以可以保证消息接受与发送的顺序。

消息广播过程中，leader会为每个事务请求生成的proposal进行广播，并且在广播前会为proposal分配一个全局单调递增的唯一ID(ZXID)，称为事务ID。leader服务器给每个follower服务器都分配 一个单独的队列，然后将事务放入这些队列，按照先进先出的策略发送。

崩溃恢复

ZAB协议规定了一些事务崩溃后的处理机制。

ZAB需要确保在leader服务器上提交的事务在所有机器上都会提交

ZAB需要确保丢弃只在leader服务器上被提出的事务。

崩溃后通常会进行重新选举下面来看一下选举过程：

1.每个server启动后都会询问其他的server需要给谁投票

2。对于其他sever发来的询问，server会根据自己的状态回复自己推荐的leader id和上一次事务处理的zxid（系统启动时推荐自己）

3.收到所有server回复以后，算出哪个zxid最大，然后将这个server设置成下一次要投票的server。

4.计算获得票数最多的server为获胜者，如果获胜者超过半数，则改server为leader,否则重修选举。

由于时间的问题，这个地方先写到这里，后续会继续更新。