微信重磅开源生产级 paxos 类库 PhxPaxos，本文向大家论述 PhxPaxos 的基石“奢侈 Paxos”。
这篇文章摘取局部我在微信外部对于 Paxos 的分享 PPT，通过注解的形式尝试与大家说明确奢侈 Paxos 的实践证实。
为何要重点说奢侈的 Paxos？集体认为这个才是 Paxos 的精华所在，也是所有 Paxos 相干算法的基石所在。另外本文将着重解说 Paxos 的算法推导过程，而不是运行过程。因为以在我学习算法的教训来看，推导过程对于把握一门算法至关重要，只有把握了实践推导过程，能力明确这个算法每一个步骤的含意。
这些 PPT 内容大部分都引自 Lamport 的论文 “The Part-Time Parliament” .
页 1 注解
这是 PPT 的题图，摆在两头的正是 Paxos 最为重要的三条束缚，把握这三条束缚，即可把握奢侈 Paxos。
页 2 注解
在正式开始解说之前，心愿抛开所有对 Paxos 的开展，而回到最奢侈的 Paxos。最奢侈的 Paxos 解决什么问题？这里举个例子：三个人别离只容许呆在不同的三个城市，他们手上有一张纸和一支笔，他们能够在纸上写下任何内容，然而，当他们停下他们的笔之后，咱们心愿三个人最初写下的内容都是一样的。
这个就是最奢侈的 Paxos 尝试解决的问题，确定一个值。临时千万别去想更多的货色，聚焦在确定一个值这么一个看似非常简单的事件身上。
页 3 注解
直入主题，提出一轮投票的定义。通过投票来决定一个提议，是一个十分原始的办法，也是十分显然的公理，这里不开展说。这里提议对应刚刚说到的这个值。这一页每个定义都要弄明确，因为上面会经常用到这些定义。比方你要记住，一轮投票会有一个编号标识他们，称之为 Bbal。你还要了解汇合的意思，一轮投票汇合 B 概括了这一轮投票的所有参加人，投票编号，提议，以及投票状况等。
比拟难了解的 Bqrm 这里开展解释一下：一轮投票取得通过，必须有 Bqrm 的人进行了投票，这个 Bqrm 每次可能都是不同的汇合，然而它的特色是必定超过总体投票成员的半数，也就是咱们常说的多数派。
页 4 注解
很显然，一轮投票是解决不了一致性问题的，因为任意一个人都有可能去发动投票，而不能靠上帝去指定某个人去发动，所以必然会面临多轮投票带来的问题。这里提出多轮投票的定义。留神这个多轮投票汇合的定义是希腊字母 Beta，一轮投票汇合是大写字母 B，是不一样的。咱们心愿寻求办法解决多轮投票带来的抵触，从而去达到确定一个值的指标。
!
页 5 注解
最重要的定义 MaxVote 的提出。要尝试解决多轮投票带来的抵触问题，必然要去建设多轮投票之间的分割，MaxVote 是一个分割。
MaxVote 通过给出一个编号，以及成员，能够在多轮投票外面找到这些成员小于这个编号的所有投票当中，最大编号的那个投票。而后咱们心愿用到这次投票对应的提议。仔细阅读样例表格外面的每个 MaxVote，从而去了解这个定义。
页 6 注解
在提出了所有数学定义后，就能够去了解这最柔美的三个约束条件了。正是通过这三个束缚，使得多轮投票的抵触问题失去解决。
第一点很好了解，要求每轮投票的编号惟一。第二点要求任意两轮投票的 Bqrm 交加不为空，其实意思很明确，就是要求 Bqrm 超过半数的意思。第三点是解决抵触的关键所在，它强行束缚了每轮投票的提议，使得这轮投票的提议不与之前的产生抵触。艰深一点讲就是，一旦我发现在我之前曾经有人投过某个提议的票，那我就要用这个提议，并且是我之前最大编号的投票对应的提议，作为我这次的提议。
页 7 注解
这是在三个约束条件之下的多轮投票过程。重复浏览这两页，从而了解约束条件 3。留神在约束条件下，提议内容的变动。
!
页 8 注解
看似这个投票过程能够引出最终统一的提议内容，但严格的算法推导必然须要严格的证实。这里提出反证法。
页 9 注解
这一页已将证实过程进行简化，置信通过你们认真的斟酌，必定是能够搞明确的。留神表格外面的样例，当编号为 2 的这轮投票曾经通过后，又呈现了一轮编号为 3 的投票（2 和 3 两头不可能存在一轮投票），提议跟之前的抵触。咱们通过推导得出这个状况是不存在的。
页 10 注解
后面只是提出 MaxVote 的定义，这里解释计算这个 MaxVote 的实际操作过程。其实就是咱们习用的轮询法，一一问呗。只有每次发动投票前，都想多数派的成员逐个询问它们比我以后这轮投票编号小的最大编号投票，即可取得整个汇合的 MaxVote，从而确定以后这轮投票的提议。
页 11 注解
聪慧的读者可能早曾经发现问题了，咱们上文所说的多轮投票，仿佛编号都是严格递增的，然而现实情况齐全不是这样，事实的多轮投票往往都是乱序的，这个大家应该毫无疑问。那么在这种状况下，MaxVote 的值可能是会错的。设想一下，在算出一个 MaxVote(5,…) 之后，才呈现一个编号比 5 小的投票，那么这个投票很有可能会影响到这个 MaxVote 的值。也就是一个先来后到的乱序问题。而如果 MaxVote 是错的，咱们的证实就生效了。
页 12 注解
为了满足这个束缚，咱们须要对 MaxVote 的计算过程进行束缚。
看过 Paxos 算法过程的，且是聪慧的读者，看完这页可能会想起，哦原来 Prepare 的 Promise 要求是这么来的。
页 13 注解
到这里算法曾经是十分欠缺了，剩下就是怎么将这个算法引申到计算机上，在计算机层面上提出算法的过程。大家能够看到理论的算法过程，很多角色都是与咱们刚刚形容的货色绝对应的。
页 14 注解
正式算法过程，也就是 Lamport 的论文 “Paxos Made Simple” 提出的。
我心愿大家再回头看这个算法过程时候，晓得每一步的含意，以及背地的实质。
页 15 注解
一个过程演示，这个就不多解释了。
结语
奢侈 Paxos 算法不容易，须要重复的斟酌，倡议有急躁的读者多看几遍，只有有急躁，必定是能够弄懂的。对于这个算法有什么用？如何去实现？请查看咱们的历史文章，外面有更多分享。
本文系微信后盾团队, 如有进犯, 请分割咱们立刻删除
github 开源地址：
https://github.com/tencent-we…
OpenIMgithub 开源地址：
https://github.com/OpenIMSDK/…
OpenIM 官网：https://www.rentsoft.cn
OpenIM 官方论坛：https://forum.rentsoft.cn/
更多技术文章：
开源 OpenIM：高性能、可伸缩、易扩大的即时通讯架构
https://forum.rentsoft.cn/thr…
【OpenIM 原创】简略轻松入门 一文解说 WebRTC 实现 1 对 1 音视频通信原理
https://forum.rentsoft.cn/thr…