提示：本文共有 1468 个字，阅读大概需要 3 分钟。
首先ZAB协议是专门为分布式协调服务ZK设计的一种支持崩溃恢复的原子广播协议,而ZK也主要依赖ZAB协议来实现分布式数据一致性.ZAB的核心是定义了那些可以改变ZK服务器数据状态的事物请求的处理方式:所有请求必须由一个全局唯一的服务器来协调处理,这样的服务器被称为Leader,而余下的其他服务器被称为Follower服务器,Leader服务器负责将一个客户端事务请求转成一个事务提议Proposal,并将该提议分发给集群中的所有Follower服务器,之后Leader服务器等待所有Follower服务器的反馈,如果有超过半数的Follower服务器进行了正确的反馈,那么Leader就会再次向所有的Follower服务器分发Commit消息,要求其将一个事务提议进行提交。并且需要保证一个全局的变更被顺序应用.ZAB协议的两种模式:消息广播 崩溃恢复消息广播:ZAB协议的消息广播模式类似于2PC.对于客户端的事务请求,Leader服务器会为其生成对应的事务Proposal,并将其发送给集群的其余服务器,然后分别收集各自的选票,最后进行事务提交.区别于2PC的是2PC的提交阶段要求等待所有事务参与者响应Yes在做Commit,而ZAB只要求过半,所以移除了中断逻辑,所有的Follower服务器要么正常反馈Leader提出的事务Proposal,要么抛弃Leader,而我们只需要在过半的Follower响应了Ack之后就开始提交事务Proposal了,而不需要等待集群中所有的Follower服务器都反馈响应.在消息广播过程中,Leader服务器会为每个事务请求生成对应的Proposal来进行广播,并且会为Proposal分配一个全局单调递增的唯一ID,称之为事务IDZXID,Leader服务器会为每一个Follower服务器都各自分配一个单独的队列,然后将需要广播的Proposal一次放入这些队列中,这样就保证了消息的严格因果关系.当Leader服务器接受到超过半数Follower的Ack响应后,就会广播一个Commit消息给所有的Follower服务器让其进行事务提交,同时Leader自身也会完成事务提交而每一个Follower在接受到Commit消息后也会完成事务提交.崩溃恢复:当整个服务框架在启动的过程中,或者是Leader服务器出现网络中断 崩溃退出 重启 等异常情况时, ZAB协议就会进入恢复模式并选举产生新的Leader服务器,当选举产生新的Leader服务器后同时集群中已经有过半的机器与该Leader服务器完成了状态同步后ZAB协议就会退出恢复模式.两种恢复模式的情况:ZAB协议需要确保那些已经在Leader服务器上提交的事务最终被所有服务器都提交ZAB协议需要丢弃那些只在Leader服务器上提出不是提交的事务.所以Leader选举算法需要保证Leader服务器拥有集群中所有机器的最高编号ZXID的事务Proposal,同步部分所有正常运行的服务器,要么称为Leader,要么称为Follower并和Leader保持同步,Leader服务器会为每一个Follower服务器准备一个队列,并将那些没有被各Follower服务器同步的事务以Proposal消息的形式逐个发送给Follower服务器然后在发一个Commit消息,来表示该事务已经提交,等到Follower服务器将Leader中的事务都同步过来后,Leader就会将Follower服务器加入到真正的可用的Follower列表.
看到此处说明本文对你还是有帮助的，关于“每天十道面试题”留言是大家的经验之谈相信也会对你有益，推荐继续阅读下面的相关内容，与本文相关度极高！
