深入理解分布式（一） —— 一张图理解Paxos算法

序

---

首先我们知道，Paxos算法，是一种基于消息传递且具有高度容错特性的共识（consensus）算法。这里我们不对它的发展和目标进行展开，如果有不清楚的可以参考wiki：https://zh.wikipedia.org/zh/Paxos%E7%AE%97%E6%B3%95

Paxos算法很强大，但同样也很难理解，那为什么我们还需要耗费时间去理解它呢，使用现成的解决方案不香吗？老实说，

1. 为了面试！！
2. 为了借鉴算法的思想，举一反三！！

这篇文章主要是使用流程图的方式，帮助读者抓住算法的关键点以及推导流程，使读者更容易理解并记住Paxos算法的工作原理。

概念

---

如果你还不太了解Paxos的这些核心概念，请参考wiki百科，

• Acceptor、Proposer、Learner
• 批准
• 选定 —— 被半数以上Proposer批准
• 提案 —— [编号，值]，例如 [M0,V0]，[Mn,Vn]

提案的选定

---

 

要解决：即使只有一个提案，仍然可以选定提案

要解决：由于某些Acceptor出错或其他原因
导致每个提案都无法被超出半数Acceptor批准，
即，提案无法被选定

等同于

被选定意味着至少被一个Acceptor批准，
通过满足P2a来满足P2

我们需要P1来保证提案被选定，但是由于通信是异步的，
如果一个提案，在某些提案被选定后，发送给为还未接受
任何提案的Acceptor，同时如果这个提案的Value与那些选定
提案的Value不同，此时，P1与P2a相矛盾。我们可以通过
满足P2b使得P1与P2a同时满足。

Proposer生成提案时，只需要通过保持P2c，就能满足P2b

从P1到P2c其实是一系列条件的逐步增强，我们要
证明这些条件可以满足一致性，就要进行反向推导：
P2c => P2b => P2a => P2
然后通过P2和P1来满足一致性。

通过第二数学归纳法来证明P2c可以满足P2b，即：

1. 先证明，在P2c的前提下，Mn=M0+1时
   结论成立
2. 再证明，在P2c的前提下，当假设M0+1到
   Mn-1都成立时，Mn也成立。
3. 最终可归纳出：
   当每个Proposer按照这个P2c的条件产生提案时，
   就能满足P2b了

P1 ：一个Acceptor必须批准它收到的第一个提案

选定一个提案，需要半数以上的Acceptor批准

一个Acceptor可以批准多个提案

结论：允许多个提案被选定，但被选定的提案必须
具有相同的Value值

P2：如果『M0,V0』被选定, 所有比M0大的提案，
且被选定，其Value也必须是V0

P2a：如果『M0,V0』被选定, 所有比M0大的提案，
且被Acceptor批准，其Value也必须是V0

P2b：如果『M0,V0』被选定，之后Proposer产生的
编号更高的提案，其Value都为V0

P2c：如果『Mn,Vn』被提出, 那么肯定存在一个半数以上
Acceptor组成的集合S，满足以下条件中的任意一个：

• S中不存在批准过编号小于Mn的提案的Acceptor。
• 选取S中所有Acceptor批准的编号小于Mn的提案，
  其中编号最大的那个提案的Value值必须是Vn。

实际上P2c规定了Proposer产生提案的方式，
当每个Proposer按照这个规则产生提案时，就能
满足P2b了。
P2b => P2a => P2不难理解，对于P2c => P2b
我们可以通过第二数学归纳法来证明：
    首先假设提案『M0,V0』被选定了，设比该提案编号
更大的提案为『Mn,Vn』，我们需要证明在P2c的
前提下，对于所有『Mn,Vn』，存在Vn = V0

关注作者公众号，随时了解更多干货！

---

往期推荐

---

• 解决Java开发中使用POI读写Excel时面对的两个麻烦
• 从简历被拒到收割今日头条offer，我花了一年时间
• Redis之坑：完全理解Redis事务
• 完全理解TCP/UDP、HTTP长连接、Websocket、SockJS/Socket.IO以及STOMP的区别和联系（改）
• Nginx之坑：完全理解location中的index，配置网站初始页（改）
• 安全（一）— 完全理解RSA加密算法
• Spring AOP之坑：完全搞清楚advice的执行顺序