绑定完请刷新页面
取消
刷新

分享好友

×
取消 复制
Paxos分布式系统共识算法?我愿称其为点歌算法…
2022-10-28 17:11:37

哈喽大家好啊,我是Hydra。

分布式系统共识算法Paxos相信大家都不陌生,它被称为难理解的算法不是没有道理的,首先,它的发表之路就充满了坎坷。

1990年,莱斯利·兰伯特大佬写了一篇论文,举了一个城邦选举的例子来介绍Paxos算法,然而大佬的幽默感并未得到审稿人的认可,论文未发表成功…

1998年,兰伯特重新发表论文《The Part-Time Parliament》描述算法,然而众多学者并不买账,直呼看不懂…

2001年,兰伯特对算法的描述进行简化,再次发表 《Paxos Made Simple》,这次Paxos成为了世界公认的分布式系统共识算法…

其实说白了,Paxos算法要解决的问题是一个分布式系统如何就某个值决议达成一致。比如说,一组进程现在正在提议某个数据的值,需要通过消息传递的方式使这个值达成一致,也就是终仅能有一个值被选定。

但毕竟是大佬写出来的东西,且不说逻辑推理部分,就算单拎出来论文中对两个核心阶段的描述来说,我等凡人理解起来也还是有些困难。

不信?那就让英语六级的我先来简单地翻译一下。

阶段1

a、提案者选择一个提案号n,发送一个提案号为nprepare请求给大多数接受者。

b、如果一个接受者收到的编号为nprepare请求,并且编号比它已经响应过的任何prepare请求的编号都大,那它就回应这个请求,承诺不再接受任何编号小于n的提案,并回复它已经接受的编号大的提案(如果存在的话)。

阶段2

a、如果提案者收到大多数接受者关于它编号为nprepare请求的回应,它就给这些接受者发送一个编号为n,值为vaccept请求,v是收到的回应中编号大的提案值。如果之前不存在任何一个提案的回复时,那么v可以是任意值,也就是可以由自己指定。

b、接受者收到编号为naccept请求时,只要它还没有响应编号比n更高的prepare请求,那么它将接受该提案。

是不是还看不懂?那就对了,下面我们通过一个简单的例子来描述这个过程。

记得小时候,有不少广播电台可以通过电话点歌,打电话给话务员告诉她你要点的歌,接下来就会播放。当然了,这个过程不是免费的,肯定有不少小伙伴在月末父母交话费的时候,惨遭过社会的毒打。

既然是电台热线,那么肯定不只有一个话务员了,我们假定这个电台同时存在3个话务员,并且她们之间是相互没有交流的,那么当短时间内打进来很多电话时,要怎么决定放哪首歌呢?

首先,话务员之间遵从少数服从多数,那么为了获得更多话务员的支持,你可以不断给更多的话务员打电话。

其次,前面我们说过,这个过程是收费的,假定存在一条潜规则,电台会更偏向于接受出价高的人的点歌请求,那么也就好办了,你可以使了劲地加钱。

在这种环境下,听众想要点歌成功的话,就得靠上面两个办法。

这时,个听众打进来电话了,在个阶段听众只能进行报价,还不能提出自己想要听什么歌,这个报价就可以理解为算法中的编号n

因为听众1是个打进热线电话的,在他之前还不存在任何报价,所以这里话务员们会无条件地先接受个听众的报价并记录下来,然后返回给听众1一个回复信息。

在回复的信息中,话务员不但需要告诉听众他的报价目前高,已经被认可了,还要说明之前没有接受过其他任何听众的点歌请求。

这时候听众1一看,自己已经获得了超过半数以上的话务员的认可了,那么进入阶段2,告诉话务员自己想要听什么歌曲。当然,在这个过程中,还得顺带着告诉话务员自己在上一阶段中的报价是多少。

于是,听众1再次打进热线,先单独向话务员2发起了选歌提议。

在收到听众1的点歌请求后,话务员2看到听众1在请求中携带的之前报价是1块,满足大于等于自己记录的大报价这一条件,于是果断接受听众1的点歌请求。

在接受点歌请求后,话务员2要记录的东西又要增加了,她不但要记住已接受的请求的报价金额,还要记住已接受请求的点播歌曲。然后给听众1一个回复,表示我已经接受了你的点歌请求。

当然了,在听众1努力点歌的时候,其他听众也不会闲着对不对?

听众2虽然打进电话晚了点,但是直接发动钞能力,把自己的报价提升到了两块,来和话务员们进行通话。

由于两块钱的报价高于本地记录的高报价,所以话务员1和话务员2都会认可这个报价,所以她们会先把本地的高报价值更新为两块。

但是接下来,由于本地记录的信息有所不同,所以她们将会给出不同的答复。

如果这时候,再来一个听众3打进电话,并且尝试以两块或以下的价格进行报价给前两个话务员的话,那么他的报价不会得到话务员的认可。

这是因为我们前面说过了,话务员们都遵循拜金主义这一潜规则,所以她们不会接受比已记录的高报价还要低的报价。

在拒绝了听众3之后,我们再回到前面的两位听众这边。

接下来,我们根据听众1和2谁先打进电话,把时间线划分为两个平行宇宙。

平行宇宙1

在平行宇宙1这条时间线里,我们假设听众1先打进电话。

这时,仍然只有话务员2接受了听众1的点歌请求,于是听众1继续向其他话务员拨打电话,告诉她们自己要听的歌。

在话务员3这里,她记录的高报价还是听众1之前的1块,所以没有意外,话务员3会接受听众1的点歌请求,并更新本地的记录信息。

但是话务员1这就不一样了,她所认可的报价已经涨到了2,所以旧的1块钱报价已经不能在她这里点歌了,因此话务员1会拒绝听众1的点歌请求。

尽管请求没有得到话务员1的接受,但是前面我们说了,话务员之间要遵循少数服从多数的原则,听众1的点歌请求已经被半数以上话务员接受,那么听众1确认自己点的这首《东风破》已被选定。

平行宇宙2

让我们回到平行宇宙的分叉点,先回顾一下前情,这时听众2已经向话务员1和话务员2发出过报价,并从话务员2那里得知她已经以1块钱的报价接受了《东风破》这首歌的提案。

那么在这条时间线中,我们让听众2先打给1、2号话务员。

听众2这时心里会想,我们杰迷们都是有素质的人,尽管我之前想听的是《简单爱》,但听一下《东风破》貌似也挺不错,那么我干脆支持听众1的选择吧。

于是,报价已被认可的他再次拿起电话打给两位话务员,发起点歌请求。

话务员1和话务员2再次比较听众2这次携带的之前报价,均大于等于本地记录的高报价,所以接受他的点歌请求。在更新本地记录的信息后,回复信息给听众2。

于是,听众2的点歌请求也获得了半数以上话务员的承认,那么听众2确认自己点的歌被选定。

看到这里,是不是似乎感觉世界线产生了收束,难道之后的每一种结果都是《东风破》将被选定?

其实,Paxos算法中精彩的部分在于它更像是一场博弈,棋局中的每一步,都可能影响终的结果。

平行宇宙β

让我们把分叉点上的时间,再往前多回溯一点,回到下面这个时间点的状态,这时话务员2刚接受了听众1的点歌请求,而听众2还没有开始打热线电话。

这次,我们站在上帝视角,让听众2改变一下选择,既然话务员2已经被别人收买了,那么干脆避其锋芒,直接向话务员1、3报价。

可想而知,听众2的报价会被两位话务员都认可。

在收到了半数以上话务员的报价认可后,听众2先向话务员1发起点歌请求。

话务员1比对一下报价,嗯,没有问题,更新本地的记录,接受他的点歌请求。

讲道理,现在的形势对听众2真的是一片大好,只要再打个电话给话务员3,就能够成功点歌了。

但是这个节骨眼上,听众2的室友喊他了,说:听歌多没意思,咱们一起来打一局刀塔吧。

听众2一想,没毛病,那我先不点歌了。

而这时,听众1回过神来了,他在之前报价阶段可是获得过半数以上的认可的,于是他带着之前被认可的报价打电话进来点歌。

可是在两位话务员那里,记录的高报价已经升到了两块了,于是听众1的点歌请求会被拒绝。

到这,我们梳理一下,听众1的点歌请求得到了1个接受、2个拒绝,也就是说他的提议没有被过半数以上的话务员接受。

无奈,听众1只能回到阶段,从报价开始再重头走一遍流程。并且这次,他把报价提升到了3块。

三位话务员收到新的报价请求后,都会表示认可,并且返回自己本地记录的信息。

听众1这一次收到的三条报价认可中,有两条携带了之前被接受的点歌信息。那么新问题来了,他应该选哪一首歌曲作为自己接下来要点播的歌曲呢?

在这里,听众要遵循的规则其实和话务员一致,他需要在这些返回的报价及歌曲信息中,选择高报价的歌曲,作为自己的接下来选歌的依据,因此他终会选择《简单爱》。

终,在没有其他听众中途打进电话干扰的情况下,三位话务员都会接受听众1的点歌请求。

终,听众1的点歌请求收到超过半数话务员的接受,于是他确认《简单爱》这首歌会被选中。

前面提到过,Paxos算法中的选举过程就像是一场博弈,场上局势瞬息万变。

回顾一下上面3条不同的时间线,打进电话顺序的不同、选择的话务员不同,都可能导致终产生不同的结果。

而Paxos算法本身,并不关注终选择的是哪一个结果,它关注的是无论如何,在后一定要能够达成一个共识。

当然了,也有可能遇到下面这种无法解决的情况…

在这种情况下,可能会有两个听众交替报价成功,却提议歌曲失败,形成一个活锁的局面。如果这样下去,有可能一整天下来,一首歌曲都没有被终选取成功。

所以在某些情况下,需要选取一个主提案者,只有主提案者才能和过半的接受者进行通信提出提案。

说白了,也就是我们常说的话事人。

那么,我们后再做一个总结,其实在我看来,Paxos算法的关键,就在于后者要认同前者,来避免无休止的争端。

本文也只是对决议部分的两阶段通过示例进行了说明,并忽略了算法中另一个角色学习者的内容,如果有兴趣的话,大家不妨去看看论文原文。

毕竟兰伯特大佬都说了:



论文原文:

http://lamport.azurewebsites.net/pubs/paxos-simple.pdf

那么,这次的分享就到这里,我是Hydra,我们下篇再见。

分享好友

分享这个小栈给你的朋友们,一起进步吧。

分布式数据库中间件 DDM
创建时间:2022-09-21 09:22:37
分布式数据库中间件 DDM
展开
订阅须知

• 所有用户可根据关注领域订阅专区或所有专区

• 付费订阅:虚拟交易,一经交易不退款;若特殊情况,可3日内客服咨询

• 专区发布评论属默认订阅所评论专区(除付费小栈外)

技术专家

查看更多
  • 飘絮絮絮丶
    专家
戳我,来吐槽~
基础设置

用户名

昵 称 修改

微 信 去绑定

取消
保存