理解分布式一致性:Paxos协议之Generalized Paxos & Byzantine Paxos

在前面一篇文章我们讲到了理解分布式一致性:Paxos协议之Cheap Paxos & Fast Paxos,本篇文章我会讲解Paxos协议的另外两个变种:Generalized Paxos和Byzantine Paxos。

Generalized Paxos

我们大家都知道,分布式一致性的最大问题就是数据同步的问题,而产生问题的原因就是冲突,按照之前讲到的各种Paxos协议方案,发生了冲突之后就必须解决冲突然后重新发送请求,这样就会提高数据同步的成本和时间,那么有没有更好的方式来解决这个问题呢?

答案肯定是有。在分布式系统中,冲突是不可避免的,遇到冲突的时候是不是每次都解决冲突然后重新发送请求呢?我们举个例子:

如果Client1发送请求ReadA,Client2 发送请求ReadB,系统4个Acceptors,有2个接收ReadA,有2个接收ReadB,在共识层面来说,因为没有达到最大的共识个数,达不成共识,需要重新发送。但是如果我们仔细观察一下两个请求,ReadA,ReadB这两个命令是没有任何联系的,无论先执行哪一个都是同样的效果。那么我们可以认为这种情况是没有冲突的,我们在执行层面自行安排两个请求的顺序,而不用再次共识。 这就叫做Generalized Paxos。

这种共识的前提就是不同命令的先后顺序无关。下面以序列图的形式更加详细的介绍:

Client1Client2LeaderAcceptor1Acceptor2Acceptor3LearnerAccept!(ReadA)Accept!(ReadA)Accept!(ReadA)Accept!(ReadA)Accept!(ReadB)Accept!(ReadB)Accept!(ReadB)Accept!(ReadB)Leader and Acceptor1Accepted(N,<ReadA,ReadB>), Acceptor2and Acceptor3Accepted(N,<ReadB,ReadA>),顺序无关,不冲突,最终值Accepted(N,<ReadA,ReadB>)Accepted(N,<ReadA,ReadB>)Accepted(N,<ReadA,ReadB>)Accepted(N,<ReadA,ReadB>)Accepted(N,<ReadA,ReadB>)下面是冲突的情况,WriteA和ReadA同时发生,产生冲突时,Leader自行解决冲突,需要重发请求Accept!(ReadA)Accept!(ReadA)Accept!(ReadA)Accept!(ReadA)Accept!(WriteA)Accept!(WriteA)Accept!(WriteA)Accept!(WriteA)Accepted(N,<ReadA,WriteA>)Accepted(N,<ReadA,WriteA>)Accepted(N,<WriteA,ReadA>)Accepted(N,<WriteA,ReadA>)冲突产生,Leader根据协议自行决定执行顺序,这里是<ReadA,WriteA>,N+1Accept!(N+1,<ReadA,WriteA>)Accept!(N+1,<ReadA,WriteA>)Accept!(N+1,<ReadA,WriteA>)Accepted(N+1,<ReadA,WriteA>)Accepted(N+1,<ReadA,WriteA>)Accepted(N+1,<ReadA,WriteA>)Client1Client2LeaderAcceptor1Acceptor2Acceptor3Learner

Byzantine Paxos

最后一个我们要讲的Paxos协议是Byzantine Paxos。熟悉虚拟货币的人应该对拜占庭协议并不陌生,这里我们也不多讲拜占庭协议,后面我会用单独的文章来详细介绍拜占庭协议。

上面我们讲到的所有的Paxos协议,只讲到了服务出错的情况,并没有考虑服务伪造篡改信息的情况,即并没有考虑到恶意节点。而拜占庭协议就是为了解决这个问题而产生的。

Byzantine Paxos比正常的Paxos协议多了一个消息验证的过程,这个验证使用了拜占庭协议。

Byzantine Multi-Paxos

下面是个Byzantine Multi-Paxos的序列图:

ClientProposerAcceptor1Acceptor2Acceptor3LearnerRequestAccept!(N,I,V)Accept!(N,I,V)Accept!(N,I,V)验证消息Verify(N,I,V) - BROADCASTVerify(N,I,V) - BROADCASTVerify(N,I,V) - BROADCASTVerify(N,I,V) - BROADCASTAccepted(N,V)Accepted(N,V)Accepted(N,V)Accepted(N,V)Accepted(N,V)Accepted(N,V)Response(V)ClientProposerAcceptor1Acceptor2Acceptor3Learner

Fast Byzantine Multi-Paxos

同样的也会有Fast Byzantine Multi-Paxos,为了更加Fast,本协议将Verify和Accepted进行融合,放在一步完成。

ClientAcceptor1Acceptor2Acceptor3LearnerAccept!(N,I,V)Accept!(N,I,V)Accept!(N,I,V)验证消息,同时AcceptedAccepted(N,I,V) - BROADCASTAccepted(N,I,V) - BROADCASTAccepted(N,I,V) - BROADCASTAccepted(N,I,V) - BROADCASTAccepted(N,I,V) - BROADCASTAccepted(N,I,V) - BROADCASTAccepted(N,I,V) - BROADCASTResponse(V)ClientAcceptor1Acceptor2Acceptor3Learner

更多教程请参考flydean的博客

理解分布式一致性:Paxos协议之Generalized Paxos & Byzantine Paxos的更多相关文章

  1. 理解分布式一致性:Raft协议

    理解分布式一致性:Raft协议 什么是分布式一致性 Leader选举 日志复制流程 term选举周期 timeout 选举和选举timeout 选举分裂 日志复制和心跳timeout 在分布式系统中, ...

  2. 理解分布式一致性:Paxos协议之Basic Paxos

    理解分布式一致性:Paxos协议之Basic Paxos 角色 Proposal Number & Agreed Value Basic Paxos Basic Paxos without f ...

  3. 理解分布式一致性:Paxos协议之Cheap Paxos & Fast Paxos

    理解分布式一致性:Paxos协议之Cheap Paxos & Fast Paxos Cheap Paxos Message flow: Cheap Multi-Paxos Fast Paxos ...

  4. 理解分布式一致性:Paxos协议之Multi-Paxos

    理解分布式一致性:Paxos协议之Multi-Paxos Multi-Paxos without failures Multi-Paxos when phase 1 can be skipped Mu ...

  5. 理解分布式一致性:拜占庭容错与PBFT

    理解分布式一致性:拜占庭容错与PBFT 拜占庭问题 拜占庭容错BFT PBFT(Practical Byzantine Fault Tolerance) why 3f+1 ? PBFT 的优点 PBF ...

  6. 理解分布式一致性与Raft算法

    理解分布式一致性与Raft算法 永远绕不开的CAP定理 出于可用性及负载方面考虑,一个分布式系统中数据必然不会只存在于一台机器,一致性简单地说就是分布式系统中的各个部分保持数据一致 但让数据保持一致往 ...

  7. 从分布式一致性到共识机制(一)Paxos算法

    从分布式系统的CAP理论出发,关注分布式一致性,以及区块链的共识问题及解决. 区块链首先是一个大规模分布式系统,共识问题本质就是分布式系统的一致性问题,但是又有很大的不同.工程开发中,认为系统中存在故 ...

  8. 11张PPT介绍Paxos协议

    之前翻译了<The Part-Time Parliament>一文,论文非常经常,强烈推荐读一读原文.翻译完论文后,希望自己能用简单的描述来整理自己的理解,所以花了一些时间通过PPT的形式 ...

  9. 分布式一致性算法:Raft 算法(论文翻译)

    Raft 算法是可以用来替代 Paxos 算法的分布式一致性算法,而且 raft 算法比 Paxos 算法更易懂且更容易实现.本文对 raft 论文进行翻译,希望能有助于读者更方便地理解 raft 的 ...

随机推荐

  1. Cows POJ - 2481 (树状数组 + 单点更新 + 区间查询)

    Cows 思路:我们可以按照每个范围的S从小到大排序,相同的S按E从大到小排序,这样的好处是当前范围的S一定大于等于之前范围的S(即当前的范围可能被之前范围的包围),那么我们只需要统计之前的范围E比当 ...

  2. Java多线程工具类之循环栅栏计数器

    Java多线程下循环计数器 本文主要内容:CyclicBarrier(下文中凯哥就用cycBar来代替)定义介绍:举例说明:代码演示:从源码来看原理及总结:CyclicBarrier与CountDow ...

  3. mysql清空表后id重1开始

    通过"truncate table 表名"方式重置清空id,让id从1开始自动递增,

  4. Visual Studio Code 1.44 设置简体中文界面语言(小白图文教程)

    作为一款微软出品的编辑器,安装完毕后,默认界面竟然不是中文!而更“丧心病狂”的是菜单里竟然连“设置”或“设置语言”这种PC软件常见选项也没有!!这种设计对小白而言简直 反!!!人!!!类!!! (默认 ...

  5. (js描述的)数据结构[哈希表1.2](9)

    一. 优秀的哈希函数 1.快速的计算: 需要快速的计算来获得对应的hashCode(霍纳法则来减少乘除次数) 2.均匀的分布: 尽可能将元素映射到不同的位置,让元素在哈希表中均匀分布 二.哈希表的扩容 ...

  6. ensp的基础路由命令,接口,下一跳的配置,入门必备

    关于ensp入门事情,第一件事当是安装必备三件套:而后,应该是接触路由和PC机了,最烦人满屏代码,眼花缭乱: 今天写一篇零基础接触ensp的首次操作,PC-路由-路由-PC的互通实验: 实验要拉出两台 ...

  7. .Net微服务实战之技术架构分层篇

    一拍即合 上一篇<.Net微服务实战之技术选型篇>,从技术选型角度讲解了微服务实施的中间件的选择与协作,工欲善其事,必先利其器,中间件的选择是作为微服务的基础与开始,也希望给一直想在.Ne ...

  8. scala_spark实践3

    Spark 读写HBase优化 读数据 可以采用RDD的方式读取HBase数据: val conf = HBaseConfiguration.create() conf.set(TableInputF ...

  9. vue 中 history 模式的配置和打包

    在使用 vue 进行项目开发中,默认的路由形式是 hash,表现形式就是 url 中始终带有 # 号,在后台管理类的项目中并不影响使用,但是在特殊场景,比如微信分享的H5链接中,微信会自动拼接参数,由 ...

  10. @suppressWarnings("unchecked") java 中是什么意思 (一般放dao查询方法上)

    J2SE 提供的最后一个批注是 @SuppressWarnings.该批注的作用是给编译器一条指令,告诉它对被批注的代码元素内部的某些警告保持静默. 一点背景:J2SE 5.0 为 Java 语言增加 ...