实例介绍
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的事务数据。
小贴士
感谢您为本站写下的评论，您的评论对其它用户来说具有重要的参考价值，所以请认真填写。
- 类似“顶”、“沙发”之类没有营养的文字，对勤劳贡献的楼主来说是令人沮丧的反馈信息。
- 相信您也不想看到一排文字/表情墙，所以请不要反馈意义不大的重复字符，也请尽量不要纯表情的回复。
- 提问之前请再仔细看一遍楼主的说明，或许是您遗漏了。
- 请勿到处挖坑绊人、招贴广告。既占空间让人厌烦，又没人会搭理，于人于己都无利。
关于好例子网
本站旨在为广大IT学习爱好者提供一个非营利性互相学习交流分享平台。本站所有资源都可以被免费获取学习研究。本站资源来自网友分享，对搜索内容的合法性不具有预见性、识别性、控制性，仅供学习研究，请务必在下载后24小时内给予删除，不得用于其他任何用途，否则后果自负。基于互联网的特殊性，平台无法对用户传输的作品、信息、内容的权属或合法性、安全性、合规性、真实性、科学性、完整权、有效性等进行实质审查；无论平台是否已进行审查，用户均应自行承担因其传输的作品、信息、内容而可能或已经产生的侵权或权属纠纷等法律责任。本站所有资源不代表本站的观点或立场，基于网友分享，根据中国法律《信息网络传播权保护条例》第二十二与二十三条之规定，若资源存在侵权或相关问题请联系本站客服人员，点此联系我们。关于更多版权及免责申明参见 版权及免责申明
网友评论
我要评论