前言
Paxos 算法如同咱们标题大图：世界上只有一种一致性算法，就是 Paxos。出自一位 google 大神之口。html
同时，Paxos 也是出名的晦涩难懂，推理过程极其复杂。楼主在尝试理解 Paxos 算法的过程当中历经挫折。程序员
今天，楼主不会讲推理过程，由于就算是尝试使用大白话来说，也很是的难懂。固然更不会讲数学公式。算法
而是从一个普通 Java 程序员的角度来理解 Paxos 算法。数据库
1. 什么是 Paxos 算法
Paxos 算法由图灵奖得到者 Leslie Lamport 于 1990 年提出的一种基于消息传递且具备高度容错的特性的一致性算法。分布式
来看看大师的样貌：google
标准的程序员。。。。spa
Paxos 有点相似咱们以前说的 2PC，3PC，可是解决了他们俩的各类硬伤。该算法在不少大厂都获得了工程实践，好比阿里的 OceanBase 的分布式数据库，底层就是使用的 paxos 算法。再好比 Google 的 chubby 分布式锁也是用的这个算法。可见该算法在分布式系统中的地位，甚至于，paxos 就是分布式一致性的代名词。翻译
2. Paxos 解决了什么问题
那么它解决了什么问题呢？ 答：解决了一致性问题。3d
什么是 consensus （一致性）问题？code
在一个分布式系统中，有一组的 process，每一个 process 均可以提出一个 value，consensus 算法就是用来从这些 values 里选定一个最终 value。若是没有 value 被提出来，那么就没有 value 被选中；若是有1个 value 被选中，那么全部的 process 都应该被通知到。
咱们假设一种状况，在一个集群环境中，要求全部机器上的状态是一致的，其中有2台机器想修改某个状态，机器 A 想把状态改成 A，机器 B 想把状态改成 B，那么到底听谁的呢？
有人说，能够像 2PC，3PC 同样引入一个协调者，谁先到，听谁的。
可是若是，协调者宕机了呢？
因此须要对协调者也作备份，也要作集群。这时候，问题来了，这么多协调者，听谁的呢？
Paxos 算法就是为了解决这个问题而生的！！！ 牛不？
下面，楼主会尝试用本身的语言配合图，来解释使用 Paxos 算法来解决这样一个相似问题的过程。若是解释的很差，还请见谅。但楼主不会去写任何的算法推导过程，若是各位想看，文末有 Paxos 论文连接，和不少大牛写的推导过程。
开始吧！
3. 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% 了，别折腾了。洗洗继续睡吧。
整个过程以下图：
4. 总结
从上面的例子能够看出：这个 Paxos 协议/算法 就是少数服从多数，标准的 鸽笼原理/抽屉原理，同时，还会根据议员的身份来判断是否须要应答，这个身份其实就是一个编号，是为了防止出现活性致使死循环。
注意：这一切都是在没有 拜占庭将军 问题的基础上创建的，即消息不会被篡改（由于分布式大多在局域网中）。
Paxos 的目标：保证最终有一个提案会被选定，当提案被选定后，其余议员最终也能获取到被选定的提案。
Paxos 协议用来解决的问题能够用一句话来简化： 将全部节点都写入同一个值，且被写入后再也不更改。
引用
如何浅显易懂地解说 Paxos 的算法？ 图解 Paxos 一致性协议 分布式系列文章——Paxos算法原理与推导 Paxos算法 维基百科，自由的百科全书 Paxos Made Simple【翻译】 The Part-Time Parliament(Paxos算法中文翻译)