一致性算法 Paxos

avatar 2020年08月13日09:48:08 6 2988 views
博主分享免费Java教学视频,B站账号:Java刘哥 ,长期提供技术问题解决、项目定制:本站商品点此

前言

世界上只有一种一致性算法,出自一位 google 大神之口。

同时,Paxos 也是出名的晦涩难懂,推理过程极其复杂。楼主在尝试理解 Paxos 算法的过程中历经挫折。

今天,楼主不会讲推理过程,因为就算是尝试使用大白话来讲,也非常的难懂。当然更不会讲数学公式。

而是从一个普通 Java 程序员的角度来理解 Paxos 算法。

 

一、什么是 Paxos 算法

Paxos 算法由图灵奖获得者 Leslie Lamport 于 1990 年提出的一种基于消息传递且具有高度容错的特性的一致性算法。

Paxos 有点类似我们之前说的 2PC,3PC,但是解决了他们俩的各种硬伤。该算法在很多大厂都得到了工程实践,比如阿里的 OceanBase 的分布式数据库,底层就是使用的 paxos 算法。再比如 Google 的 chubby 分布式锁也是用的这个算法。可见该算法在分布式系统中的地位,甚至于,paxos 就是分布式一致性的代名词

 

二、 Paxos 解决了什么问题

那么它解决了什么问题呢?

答:解决了一致性问题。

 

什么是 consensus (一致性)问题?

 

在一个分布式系统中,有一组的 process,每个 process 都可以提出一个 value,consensus 算法就是用来从这些 values 里选定一个最终 value。如果没有 value 被提出来,那么就没有 value 被选中;如果有1个 value 被选中,那么所有的 process 都应该被通知到。

 

我们假设一种情况,在一个集群环境中,要求所有机器上的状态是一致的,其中有2台机器想修改某个状态,机器 A 想把状态改为 A,机器 B 想把状态改为 B,那么到底听谁的呢?

 

有人说,可以像 2PC,3PC 一样引入一个协调者,谁先到,听谁的。

但是如果,协调者宕机了呢?

所以需要对协调者也做备份,也要做集群。这时候,问题来了,这么多协调者,听谁的呢?

 

Paxos 算法就是为了解决这个问题而生的!!! 牛不?

 

下面,楼主会尝试用自己的语言配合图,来解释使用 Paxos 算法来解决这样一个类似问题的过程。如果解释的不好,还请见谅。但楼主不会去写任何的算法推导过程,如果各位想看,文末有 Paxos 论文链接,和很多大牛写的推导过程。

 

开始吧!

三、 Paxos 例子说明

楼主这个例子来自中文维基百科,但楼主为了形象化,辅以图片解释,但愿不会让人更迷糊。

 

例子:

在 Paxos 岛上,有A1, A2, A3, A4, A5 5位议员,就税率问题进行决议。我们假设几个场景来解释:

 

场景 1.

假设 A1 说:税率应该是 10%。而此时只有他一个人提这个建议。如下图:

 

很完美,没有任何人和他竞争提案,他的这个提案毫无阻挠的通过了。A2 - A5 都会回应他:我们收到了你的提案,等待最终的批准。而 A1 在收到 2 份回复后,就可以发布最终的决议:税率定位 10%,不用再讨论了。

 

这里有个注意的地方就是:为什么收到了 2 份回复就可以确定提案了呢?

答:因为包括他自己,就达到 3 个人了,少数服从多数。

如果各位听说过鸽笼原理/抽屉原理,就明白个大概了。有人说,鸽笼原理/抽屉原理就是 Paxos 的核心思想。

 

场景 2:

现在我们假设在 A1 提出 10% 税率提案的同时, A5 决定将税率定为 20%,如果这个提案要通过侍从送到其他议员的案头,A1 的草案将由 4 位侍从送到 A2-A5 那里。但是侍从不靠谱(代表分布式环境不靠谱),负责 A2 和 A3 的侍从顺利送达,而负责 A4 和 A5 的侍从则开溜了!

 

而 A5 的草案则送到了 A4 和 A3 的手中。

 

现在,A1 ,A2,A3 收到了 A1 的提案,A3,A4, A5 收到 A5 的提案,按照 Paxos 的协议,A1,A2,A4,A5 4个侍从将接受他们的提案,侍从拿着回复:我已收到你的提案,等待最终批准 回到提案者那里。

 

而 A3 的行为将决定批准哪一个。

 

当 A3 同时收到了 A1 和 A5 的请求,该如何抉择呢?不同的抉择将会导致不同的结果。

 

有 3 种情况,我们分析一下:

 

场景2:情况一

假设 A1 的提案先送到 A3 那里,并且 A3 接受了该提案并回复了侍从。这样,A1 加上 A2 加上 A3,构成了多数派,成功确定了税率为 10%。 而 A5 的侍从由于路上喝酒喝多了,晚到了一天,等他到了,税率已经确定了,A3 回复 A5:兄弟,你来的太晚了,税率已经定好了,不用折腾了,听 A1 的吧。

 

如下图:

 

场景2:情况二

依然假设 A1 的提案先送到 A3 处,但是这次 A5 的侍从不是放假了,只是中途耽搁了一会。这次, A3 依然会将"接受"回复给 A1 .但是在决议成型之前它又收到了 A5 的提案。这时协议根据 A5 的身份地位有两种处理方式,但结果相同。

  • 当 A5 地位很高,例如 CEO,就回复 A5:我已收到您的提案,等待最终批准,但是您之前有人提出将税率定为10%,请明察。
  • 当 A5 没地位,普通码农一个,直接不回复。等待 A1 广播:税率定为 10% 啦!!!

如下图:

 

场景2:情况三

在这个情况中,我们将看见,根据提案的时间及提案者的权势决定是否应答是有意义的。在这里,时间和提案者的权势就构成了给提案编号的依据。这样的编号符合"任何两个提案之间构成偏序"的要求。

 

A1 和 A5 同样提出上述提案,这时 A1 可以正常联系 A2 和 A3,A5 也可以正常联系这两个人。这次 A2 先收到 A1 的提案; A3 则先收到 A5 的提案。而 A5 更有地位。

 

在这种情况下,已经回答 A1 的 A2 发现有比 A1 更有权势的 A5 提出了税率 20% 的新提案,于是回复A5说:我已收到您的提案,等待最终批准。

 

而回复 A5 的 A3 发现新的提案者A1是个小人物,没地位不予应答。

 

此时,A5 得到了 A2,A3 的回复,于是 A5 说:税率定为 20%,别再讨论了。

 

那 A4 呢? A4 由于睡过头了,迷迷糊糊的说:现有的税率是什么? 如果没有决定,则建议将其定为 15%.

 

这个时候,其他的议员就告诉他:哥们,已经定为 20% 了,别折腾了。洗洗继续睡吧。

 

整个过程如下图:

 

四、总结

从上面的例子可以看出:这个 Paxos 协议/算法 就是少数服从多数,标准的 鸽笼原理/抽屉原理,同时,还会根据议员的身份来判断是否需要应答,这个身份其实就是一个编号,是为了防止出现活性导致死循环。

 

注意:这一切都是在没有 拜占庭将军 问题的基础上建立的,即消息不会被篡改(因为分布式大多在局域网中)。

 

Paxos 的目标:保证最终有一个提案会被选定,当提案被选定后,其他议员最终也能获取到被选定的提案。

 

Paxos 协议用来解决的问题可以用一句话来简化: 将所有节点都写入同一个值,且被写入后不再更改

 

引用

如何浅显易懂地解说 Paxos 的算法?
图解 Paxos 一致性协议
分布式系列文章——Paxos算法原理与推导
Paxos算法 维基百科,自由的百科全书
Paxos Made Simple【翻译】
The Part-Time Parliament(Paxos算法中文翻译)

  • 微信
  • 交流学习,资料分享
  • weinxin
  • 个人淘宝
  • 店铺名:言曌博客咨询部

  • (部分商品未及时上架淘宝)
avatar

发表评论

avatar 登录者:匿名
匿名评论,评论回复后会有邮件通知

  

已通过评论:0   待审核评论数:0