ZAB协议

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

ZAB协议的开发设计人员在协议设计之初并没有要求其具有很好的扩展性,最初只 是为雅虎公司内部那些高吞吐量、低延迟、健壮、简单的分布式系统场景设计的。

在 ZooKeeper的官方文档中也指出, ZAB协议并不像Paxos算法那样,是一种通用的分布式一致性算法,它是一种特别为ZooKeeper设计的崩溃可恢复的原子消息广播算法。

总结来说,ZAB 协议就是:"主备一致性","消息广播","崩溃恢复"

流程

所有节点都会在3个状态中转换:

1:选举leader/崩溃恢复(leader宕机重新选举)

2:消息广播 (leader接收消息广播给Follower)

3:崩溃恢复(leader宕机重新选举)

在节点启动后,会寻找leader节点,没有的话将选举一个leader

选举leader成功后,所有数据写入都将经过leader,由leader发送给其他follower

当follower与leader失去联系之后,将进入崩溃恢复模式,在follower中选举一个拥有相对最新数据的节点成为leader

重新消息广播

消息广播

leader选举成功后,所有数据将写入进leader,由leader发送给其他follower

事务二阶段提交

在消息广播中,leader服务器会给每个事务提案分配一个全局单调递增的唯一事务ID,每次广播时需要保证每个事务ID的先后顺序

follower接收到广播之后,需要把事务写入到磁盘,写入成功之后给leader反馈ACK

leader接收到超过半数ACK后,广播commit信息,要求follower提交事务   

注意,每个事务ID需要严格遵守顺序

崩溃恢复

当leader服务器崩溃后,可能会出现以下情况

1:leader出现了提案5,通知时中途崩溃了

2:leader在发送提交提案5时,中途崩溃

2种情况都可能出现,这个时候所有follower数据都是不一致的

这个时候,follower选举时,需要选举一个commitID最大值的follower作为leader,每个follower选举时需要比对自己的commit ID,只有大于时才投票,这个时候可以确保新选举的leader拥有最完整的数据

前 leader恢复

事务ID是一个64位的数字,低32位记录了单调递增的事务ID,高32位记录了leader周期的编号,每次选举都会使得此值+1

在前leader恢复后,由于新leader正常工作,可能提出了新的提案5,这个时候前leader需要比对高32位编号,如果不一致,则丢弃此提案,同步新leader的数据

崩溃恢复方式类似于raft