前文：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...