ZAB
2021-05-13 13:33:35 0 举报
ZAB
作者其他创作
大纲/内容
ACK
ZAB包括两种基本模式,分别是奔溃恢复和消息广播。
FIFO
Propose
高32位代表了Leader的唯一性
Leader ID
Leader与Follower都有一一对应的消息队列,用于保证操作的顺序性,根据ZXID进行先后排序处理。
以事物日志形式写进磁盘
写入成功
……
Follower
基于这样的策略:当Foliower连接上Leader之后,Leader服务器会根据自己服务器上最后被提交的ZXID和Follower上的ZXID进行对比,要么回滚,要么与Leader同步。
Commit
崩溃恢复假设1:Leader在复制数据给所有follower之后崩溃,怎么办?假设2:Leader在收到ACK并提交了自己,同时发送了部分commit出去之后崩溃怎么办?针对这些问题,ZAB定义了两个原则: 1、ZAB协议确保那些已经在Leader提交的事务最终会被所有服务器提交。 2、ZAB协议确保丢弃那些只在Leader提出/复制,但没有提交的事务。所以ZAB设计了一个选举算法,能够确保提交已经被Leader提交的事务,同时丢弃已经被跳过的事务。针对这个要求,让Leader选举算法保证选举出来的Leader服务器拥有集群中的最大ZXID的事务,这样就可以保证新选举出来的Leader一定具有所有已经提交的提案,并且这样可以省去Leader服务器检查事务的提交和丢弃工作。
事务 ID
过半ACK
Leader
生成Proposal
低32位代表了事务的唯一性
Leader服务器维护了可用Follower的列表
文本
64位ZXID
Request
Multi-Paxos实现一系列值的共识,不关心最终达成共识的值是什么,即不关心顺序性,而ZAB实现了操作的顺序性。ZAB基于主备模式的原子广播协议,可以理解为广播一组消息,消息的顺序是固定的。整个消息广播协议基于具有FIFO特性的TCP协议来进行网络通讯的,能够很容易地保证消息广播过程中消息接收与发送的顺序性。
为Proposal分配ZXID
ZXIDLeader服务器处理或丢弃事务都是依赖ZXID的,那么ZXID如何生成?ZXID是一个64位的数字,其中低32位可以看作是一个简单的递增计数器,而高32位则代表了Leader服务器上取出本地日志中最大事务Proposal的ZXID,并从该ZXID中解析出来的epoch值然后+1。
消息广播所有副本的数据都以主节点为准,如果主节点发生故障,数据最完备的节点将当选主节点。类似二段提交,但并不是二段提交,因为Leader收到过半Follower的ACK后即可Commit(二段提交要收到全部ACK恢复YES)
0 条评论
回复 删除
下一页