Paxos分布式系统共识算法?我愿称其为点歌算法…
哈喽大家好啊,我是Hydra。
分布式系统共识算法Paxos相信大家都不陌生,它被称为难理解的算法不是没有道理的,首先,它的发表之路就充满了坎坷。
1990年,莱斯利·兰伯特大佬写了一篇论文,举了一个城邦选举的例子来介绍Paxos算法,然而大佬的幽默感并未得到审稿人的认可,论文未发表成功…
1998年,兰伯特重新发表论文《The Part-Time Parliament》描述算法,然而众多学者并不买账,直呼看不懂…
2001年,兰伯特对算法的描述进行简化,再次发表 《Paxos Made Simple》,这次Paxos成为了世界公认的分布式系统共识算法…
其实说白了,Paxos算法要解决的问题是一个分布式系统如何就某个值决议达成一致。比如说,一组进程现在正在提议某个数据的值,需要通过消息传递的方式使这个值达成一致,也就是终仅能有一个值被选定。
但毕竟是大佬写出来的东西,且不说逻辑推理部分,就算单拎出来论文中对两个核心阶段的描述来说,我等凡人理解起来也还是有些困难。
不信?那就让英语六级的我先来简单地翻译一下。
阶段1
a、提案者选择一个提案号n
,发送一个提案号为n
的prepare
请求给大多数接受者。
b、如果一个接受者收到的编号为n
的prepare
请求,并且编号比它已经响应过的任何prepare
请求的编号都大,那它就回应这个请求,承诺不再接受任何编号小于n
的提案,并回复它已经接受的编号大的提案(如果存在的话)。
阶段2
a、如果提案者收到大多数接受者关于它编号为n
的prepare
请求的回应,它就给这些接受者发送一个编号为n
,值为v
的accept
请求,v
是收到的回应中编号大的提案值。如果之前不存在任何一个提案的回复时,那么v
可以是任意值,也就是可以由自己指定。
b、接受者收到编号为n
的accept
请求时,只要它还没有响应编号比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,我们下篇再见。
相关文章