嘿，亲！知识可是无价之宝呢，但咱这精心整理的资料也耗费了不少心血呀。小小地破费一下，绝对物超所值哦！如有下载和支付问题，请联系我们QQ(微信同号)：813200300
本次赞助数额为： 2 元微信扫码支付：2 元
请留下您的邮箱，我们将在2小时内将文件发到您的邮箱
ZAB协议包括两种基本模式，即崩溃恢复和消息广播
当集群在启动过程、或者leader服务器网络中断、崩溃退出、重启等导致异常情况，ZAB协议就会进入到崩溃恢复模式，并选举产生新的leader服务器，当选举产生新的leader服务器，同时集群中有过半的机器与leader完成了数据同步后，ZAB就会退出崩溃恢复模式；可以进入到消息广播模式，当有新的机器加入到集群，集群中已经存在leader，则自动进入到数据恢复模式，找到leader服务器，并与其进行数据同步，然会一起参与到消息广播的过程中；
当集群中leader服务器崩溃退出或重启，或集群中已经不存在过半的机器与leader保持正常通信，在重新开始新一轮的原子广播之前，所有进程会先使用崩溃恢复协议来批次达到一个一致的状态，ZAB流程就会进入到崩溃恢复模式只要集群中有过半的机器能彼此之间正常通信，那么就会产生一个新的leader进入到消息广播模式
（1）消息广播
ZAB的消息广播过程使用的时一个原子广播协议，所有事务的请求必须由一个全局唯一的服务器（leader）来协调处理，而余下的服务器则成为follower服务器，针对客户端的请求，leader服务器为其产生对应的事务proposal，并发送给其余机器，然后再分别收集各自的选票，最后进行事务的提交，ZAB协议移除了二阶段提交中出现的中断逻辑，所有follower服务器要么反馈事务，要么就抛弃leader，意味着只要有过半的follower反馈响应就开始提交事务，这种无法处理leader崩溃退出带来的数据不一致问题，所以需要进入崩溃恢复模式来解决
（2）崩溃恢复
在消息广播模式过程中，一旦leader出现崩溃或者由于网络原因，leader失去了与过半follower的联系，就会进入崩溃恢复模式，选举产生新的leader(需要一个高效可靠的选举算法),并让其它机器能够快速的感知新选举的leader。ZAB协议需要确保那些已经在leader服务器上提交的事务最终被所有服务器提交，ZAB协议需要确保丢弃那些只在leader服务器上被提出的事务，选举出的leader具有集群中所有机器的最高编号的事务proposal。完成leader选举之后，在正式工作之前，leader会确认事务日志中所有proposal是否被过半的机器提交，即完成数据同步
在一个集群中，出现两个Leader，这种现象称为脑裂，脑裂的危害会使得数据同步过程出现紊乱，zookeeper的机制是每次选出Leader，会给Leader分配一个Epoch Id，并且是递增的，所以follower可以根据Epoch Id的数字号，来选择则受最大的Epoch Id的事务数据。