欢迎光临
我们一直在努力

paxos zab和raft,paxos和raft

什么是Raft? Raft一种用来管理日志复制的一致性算法 分为三个角色:leader(集群主节点)、follower(跟随节点)、candidate(无leader情况下会有follower升级为这个) 升级顺序:follower->candidate->leader? ? (不能跨级别晋升) 选举过程: – 服务刚启动全部都是follower角色,并经过一段时间才会有follower成为candidate(避免出现多个candidate分散选票),另外raft会把日志写入子节点磁盘中,允许日志落后,但是日志落后的节点无法成为leader,举个例子: — 比如有A、B、C、D、E 五个节点美国高防vps,其中AB节点挂了,CD节点是新进来的,那这种E节点的日志是最完善的,所以E会升级为candidate然后发起投票,最后获取半数赞成后成为leader。E成为leader之后就会把日志同步到CD节点(如果大家的日志都一样,那就看节点的命名顺序) 参考链接:https://zhuanlan.zhihu.com/p/25532724 图文链接:http://thesecretlivesofdata.com/raft/ ? 什么是paxos? paxos分为basic-paxos和multi-paxos,basic更复杂并且效率低,所以现在都在用multi-paxos basic-paxos流程是怎么样? * 第一阶段a(发送prepare),proposer向acceptor提出一个协议,这里的协议可以理解为client发送过来期望多节点一起保存的一致性内容,举例:一句日志,某个配置等 * 第一阶段b(计算协议vn),根据半数以上acceptor的返回,选择 max{va,vb,vc} = vn,这里的vx理解为这个acceptor已知的最大协议号,acceptor一旦返回了vx后,则表明: ????* acceptor在接下来的prepare请求中,会返回的vx自增1 ????* acceptor不会accept任何小于vx的协议请求,只会accept大于vx的协议请求 * 第二阶段a(发送决议好的vn),把vn发送给acceptor * 第二阶段b,在半数acceptor返回了成功后,再返回client成功通过协议 坑爹的地方:basic-paxos的第一阶段,接收者之后只会接收最大的vn,这样如果存在多个proposer提议者,那vn就会被频繁刷新,不同proposer就会相互锁住对应的提交 multi-paxos的优化? multi-paxos相对于basic,最大的优化点是仅有一个proposer,这样不会导致多个proposer相互锁锁住提交,我们称这个提议者为leader。省去basic-paxos的prepare阶段。 – 其选主leader的方式如下: — 最简单的选举方法是拿Server ID最大的当leader(每个leader每隔T时间向其他Server发心跳,如果2T时间内没收到更高ID心跳,那就成为leader) ? ? 参考链接:https://segmentfault.com/a/1190000018844326 ? paxos与raft区别? 1 raft仅允许日志最多的当leader,而multi-paxos任意节点都可当选leader 2 raft不允许日志空洞,multi-paxos允许 – 什么是日志空洞?就是日志中间有些信息断开了,比如假设写入了 A->B->C 数据,那日志应该是 A日志->B日志->C日志,但是multi-paxos的leader允许”A日志->缺了B->C日志”,B日志它可以异步从其他节点拉取回来,而raft就不允许这种情况,比如是完整的日志 ? 什么是ZAB? ZAB集群角色划分为leader、follower, 只有leader可以写,leader、follower都可以读。 客户端给zk发送一个写请求的时候,会有leader节点把proposal提议发送给所有follower,如果超过半数(比如5台3ack,3台2ack)给leader返回ack,(leader在发送提议前 以及 follower在返回ack前 都会把数据写入日盘日志文件), 如果leader收到超过半数ack,就会把日志文件的proposal(提议)数据加载到内存znode中,并且commit通知所有follower节点也加载磁盘日志到内存znode中。 ? 总结:角色划分(leader+follower)、2PC、过半写机制 ? 还有一个ZAB协议?这个与Paxos又有什么区别? ZAB是专门为zk设计的一种崩溃可恢复原子广播协议,他与paxos的区别在于 – ZAB额外加了一个同步阶段,新的leader会确保所有进程都已经完成之前事务proposal的提交 ? 各自用途 ZAB协议:构建一个高可用的分布式数据主备系统,例如ZooKeeper Paxos:则构建一个分布式的一致性状态机系统 63277835

赞(0)
【声明】:本博客不参与任何交易,也非中介,仅记录个人感兴趣的主机测评结果和优惠活动,内容均不作直接、间接、法定、约定的保证。访问本博客请务必遵守有关互联网的相关法律、规定与规则。一旦您访问本博客,即表示您已经知晓并接受了此声明通告。