简介ZAB协议
最后更新：2022-08-01 02:20:27 手机定位技术交流文章
ZAB简介(访谈重点)
是专门为动物园主设计的支助崩溃恢复的原子广播同意。 基于这个协议,动物园管理员实现了一个系统架构,具有主备份模式,以维持数据的一致性。
原子广播协议:向客户发送的请求,所有由领导接受(每个节点将递交书面请求给领导处理),leader将请求封装成一个事务proposal，（由于 leader 会为每一个 follower 创建一个队列，将事务置于响应队列中,保证事务的顺序性。随后, 该 建议 将 以 排队 顺序 向 其他 节点 广播, 并 向 所有 追随者 和 观察员 发出,然后根据追随者的反馈,如果超过一半答复成功(答复不成功),然后执行提交操作,先提交自己，在同步commit给所以follower。
崩溃恢复：对于崩溃恢复，有两个地方需要保证ZAB协议,第一就是 ZAB 协议需要保证已经被 leader 提交的事务最终被所有的机器提交；第二就是需要保证丢弃那些只在 leader 上提出，还未提交的事务。为了保证以上两点，在选举时选择ZXID的最大节点解决了上述问题。
事务编号zxid(epoch+事务请求计数器)
在ZAB（Zookeeper Atomic Broadcast，Zookeeper原子消息广播协议）协议的事务编号zxid设计中，zxid是一个64位数字,下面的32是一个单调的乘法计数器,对每个客户交易请求,计数器+1;高32表示领导周期时代的数目,每届选举都会产生一个新的领导服务器,你会从这个领导服务器中获得本地日志中最大的zxid时代,并+1，然后作为一个新的时代,它将从0到32位低数计数。
Zxid（Transaction id）用于标识一次更新操作的proposal（提议）id。为了保证顺序性，zkid必须单调递增。
epoch
它可以被理解为当前星团所在的年龄或时期。每个领导人就像皇帝,都有自己的年号，所以每次改朝换代，leader变更后都会在前一个年代的基础上对epoch+1.这样就算旧的leader崩溃恢复后也没有人听他的了，因为follower只听从当前年代的leader的命令。
Zab协议有两个模式-恢复模式(选择主机)和广播模式(同步)
当服务器启动或者在领导者崩溃后，zab就进入恢复模式，当领导者选定，且超过半数的server与leader完成同步之后，恢复模式就结束了。状态同步保证了leader和server具有相同的系统状态。
zab协议4阶段
1. Leader election：选举阶段
在选举阶段获得超过一半的选票的部门被选为联合领导,只有在达到广播阶段,才能成为真正的领导者。这个阶段的目的是选择一个高级领导进入下一个阶段。
2.发现:发现阶段
followers跟准leader进行通信，同步followers最近接收的proposal。这一阶段的目的是让leader生成新的epoch，让followers接受新的epoch并更新自己的accepted Epoch。
一个follower节点f尝试连接一个follower p为leader时会被拒绝，然后f会重新进入选举阶段。
Synchronization：同步阶段
主要是将leader前一阶段发现的最近接受的proposal同步到集群中所有副本上。超过半数节点同步完成时，准leader变成真正的leader。追随者只能收到比他们自己的lastZxid大的zxid建议。
广播:广播舞台
集群正式对外提供事务服务，并且leader可以进行消息广播同时,如果添加新的节点,则必须同步新的节点。
ZAB提交事务采用过半成功写策略。
本文由 在线网速测试 整理编辑，转载请注明出处。
