前文：Paxos 实践介绍 (1): 奢侈 Paxos 算法实践推导与证实
了解奢侈 Paxos 是浏览本文的前提。
Multi-Paxos
奢侈 Paxos 算法通过多轮的 Prepare/Accept 过程来确定一个值，咱们称这整个过程为一个 Instance。Multi-Paxos 是通过 Paxos 算法来确定很多个值，而且这些值的程序在各个节点完全一致。概括来讲就是确定一个全局程序。
多个 Instance 怎么运作？首先咱们先构建最繁难的模式，各个 Instance 独立运作。
每个 Instance 独立运作一个奢侈 Paxos 算法，咱们保障仅当 Instance i 的值被确定后，方可进行 i + 1 的 Paxos 算法，这样咱们就保障了 Instance 的有序性。
但这样效率是比拟差的，家喻户晓奢侈 Paxos 算法的 Latency 很高，Multi-Paxos 算法心愿找到多个 Instance 的 Paxos 算法之间的分割，从而尝试在某些状况去掉 Prepare 步骤。
上面我尝试形容一个 Sample 的演进状况来论述这个算法，因为这个算法的要点其实非常简单，而且无需更多证实。
首先咱们定义 Multi-Paxos 的参加因素：
- 3 个参加节点 A/B/C.
- Prepare(b) NodeA 节点发动 Prepare 携带的编号。
- Promise(b) NodeA 节点承诺的编号。
- Accept(b) NodeA 节点发动 Accept 携带的编号。
1(A) 的意思是 A 节点产生的编号 1，2(B) 代表编号 2 由 B 节点产生。绿色示意 Accept 通过，红色示意回绝。
下图形容了 A /B/ C 三个节点并行提交的演进过程：
这种状况下 NodeA 节点简直每个 Instance 都收到其余节点发来的 Prepare，导致 Promise 编号过大，迫使本人一直晋升编号来 Prepare。这种状况并未能找到任何的优化突破口。
下图形容了只有 A 节点提交的演进过程：
这种状况咱们会立即发现，在没有其余节点提交的烦扰下，每次 Prepare 的编号都是一样的。于是乎咱们想，为何不把 Promised(b) 变成全局的？来看下图：
假如咱们在 Instance i 进行 Prepare(b)，咱们要求对这个 b 进行 Promise 的失效范畴是 Instance[i, ∞)，那么在 i 之后咱们就无需在做任何 Prepare 了。可想而知，假如上图 Instance 1 之后都没有任何除 NodeA 之外其余节点的提交，咱们就能够预期接下来 Node A 的 Accept 都是能够通过的。那么这个去 Prepare 状态什么时候突破？咱们来看有其余节点进行提交的状况：
Instance 4 呈现了 B 的提交，使得 Promised(b) 变成了 2(B), 从而导致 Node A 的 Accept 被回绝。而 NodeA 如何持续提交？必须得进步本人的 Prepare 编号从而抢占 Promised(b)。这里呈现了很显著的去 Prepare 的窗口期 Instance[1,3]，而这种期间很显著的标记就是只有一个节点在提交。
重点：不 Prepare 间接 Accept 为啥是平安的？因为 Accept 的 b 曾经被 Promise 过。
总结
Multi-Paxos 通过扭转 Promised(b) 的失效范畴至全局的 Instance，从而使得一些惟一节点的间断提交取得去 Prepare 的成果。
题外话：这里提一下我所察看到的 Multi-Paxos 的一个误区，很多人认为 Multi-Paxos 是由 leader 驱动去掉 Prepare 的，更有说在有 Leader 的状况下能力实现 Multi-Paxos 算法，这都是了解有误。大家看到这里也应该明确这里的因果关系，Multi-Paxos 是适应某种申请特色状况下的优化，而不是要求申请满足这种特色。所以 Multi-Paxos 承受并行提交。
Leader
为何还要说 Leader，尽管 Multi-Paxos 容许并行提交，但这种状况下效率是要进化到奢侈 Paxos 的，所以咱们并不心愿长时间处于这种状况，Leader 的作用是心愿大部分工夫都只有一个节点在提交，这样能力最大施展 Mulit-Paxos 的优化成果。
怎么失去一个 Leader，真的十分之简略，Lamport 的论文甚至的不屑一提。咱们察看 Multi-Paxos 算法，首先能做 Accept(b) 必然是 b 曾经被 Promised 了，而间断的 Accept(b) 被打断，必然是因为 Promised(b) 被晋升了，也就是呈现了其余节点的提交 (提交会先 Prepare 从而晋升 b)。那么重点来了，如何防止其余节点进行提交，咱们只须要做一件事即可实现。
收到来自其余节点的 Accept，则进行一段时间的回绝提交申请。
这个解读起来就是各个节点都想着不要去突破这种间断的 Accept 状态，而当有一个节点在间断的 Accept，那么其余节点必然继续一直的拒绝请求。这个 Leader 就这样有形的被产生进去了，咱们压根没有刻意去“选举”，它就是来自于 Multi-Paxos 算法。
题外话：为何网上呈现很多非常复杂的选举 Leader 算法，有的甚至利用 Paxos 算法去选举 Leader，我觉的他们很有可能是没有齐全了解 Multi-Paxos，走入了必须有 Leader 这个误区。
用 Paxos 算法来进行选举是有意义的，但不应该用在 Leader 下面。Paxos 的利用除了写之外，还有很重要的一环就是读，很多时候咱们心愿要读到 Latest，通常的做法就是选举出一个 Master。Master 含意是在任一时刻只能有一个节点认为本人是 Master，在这种束缚下，读写我都在 Master 上进行，就能够取得 Latest 的成果。Master 与 Leader 有实质上的区别，要达到 Master 这种强统一的唯一性，必须得通过强一致性算法能力选举进去。而当咱们实现了 Paxos 算法后，选举 Master 也就变得非常简单了，会波及到一些租约的货色，前面再分享。
说的再多不如浏览源码，猛击进入咱们的开源 Paxos 类库实现：https://github.com/tencent-wechat/phxpaxos
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…