Paxos 算法

参考：

凤凰架构：https://icyfenix.cn/distribution/consensus/paxos.html

Paxos 算法将分布式系统中的节点分为三类：

• 提案节点：称为 Proposer，提出对某个值进行设置操作的节点，设置值这个行为就被称之为提案（Proposal），值一旦设置成功，就是不会丢失也不可变的。请注意，Paxos 是典型的基于操作转移模型而非状态转移模型来设计的算法，这里的“设置值”不要类比成程序中变量赋值操作，应该类比成日志记录操作，在后面介绍的 Raft 算法中就直接把“提案”叫作“日志”了。
• 决策节点：称为 Acceptor，是应答提案的节点，决定该提案是否可被投票、是否可被接受。提案一旦得到过半数决策节点的接受，即称该提案被批准（Accept），提案被批准即意味着该值不能再被更改，也不会丢失，且最终所有节点都会接受该它。
• 记录节点：被称为 Learner，不参与提案，也不参与决策，只是单纯地从提案、决策节点中学习已经达成共识的提案，譬如少数派节点从网络分区中恢复时，将会进入这种状态。

使用 Paxos 算法的分布式系统里的，所有的节点都是平等的，它们都可以承担以上某一种或者多种的角色，不过为了便于确保有明确的多数派，决策节点的数量应该被设定为奇数个，且在系统初始化时，网络中每个节点都知道整个网络所有决策节点的数量、地址等信息。

在分布式环境下，如果我们说各个节点“就某个值（提案）达成一致”，指的是“不存在某个时刻有一个值为 A，另一个时刻又为 B 的情景”。解决这个问题的复杂度主要来源于以下两个方面因素的共同影响：

• 系统内部各个节点通信是不可靠的，不论对于系统中企图设置数据的提案节点抑或决定是否批准设置操作的决策节点，其发出、收到的信息可能延迟送达、也可能会丢失，但不去考虑消息有传递错误的情况。
• 系统外部各个用户访问是可并发的，如果系统只会有一个用户，或者每次只对系统进行串行访问，那单纯地应用 Quorum 机制，少数节点服从多数节点，就已经足以保证值被正确地读写。

第一点是网络通信中客观存在的现象，也是所有共识算法都要重点解决的问题。

对于第二点，对同一个变量的并发修改必须先加锁后操作，不能让 A、B 的请求被交替处理，这些可以说是程序设计的基本常识了。而在分布式的环境下，由于还要同时考虑到分布式系统内可能在任何时刻出现的通信故障，如果一个节点在取得锁之后，在释放锁之前发生崩溃失联，这将导致整个操作被无限期的等待所阻塞，因此算法中的加锁就不完全等同于并发控制中以互斥量来实现的加锁，还必须提供一个其他节点能抢占锁的机制，以避免因通信问题而出现死锁。

为了这个问题，分布式环境中的锁必须是可抢占的。Paxos 算法包括两个阶段，其中，第一阶段“准备”（Prepare）就相当于上面抢占锁的过程。如果某个提案节点准备发起提案，必须先向所有的决策节点广播一个许可申请（称为 Prepare 请求）。提案节点的 Prepare 请求中会附带一个全局唯一的数字 n 作为提案 ID，决策节点收到后，将会给予提案节点两个承诺与一个应答。

两个承诺是指：

• 承诺不会再接受提案 ID 小于或等于 n 的 Prepare 请求。
• 承诺不会再接受提案 ID 小于 n 的 Accept 请求。

一个应答是指：

• 不违背以前作出的承诺的前提下，回复已经批准过的提案中 ID 最大的那个提案所设定的值和提案 ID，如果该值从来没有被任何提案设定过，则返回空值。如果违反此前做出的承诺，即收到的提案 ID 并不是决策节点收到过的最大的，那允许直接对此 Prepare 请求不予理会。

当提案节点收到了多数派决策节点的应答（称为 Promise 应答）后，可以开始第二阶段“批准”（Accept）过程，这时有如下两种可能的结果：

• 如果提案节点发现所有响应的决策节点此前都没有批准过该值（即为空），那说明它是第一个设置值的节点，可以随意地决定要设定的值，将自己选定的值与提案 ID，构成一个二元组“(id, value)”，再次广播给全部的决策节点（称为 Accept 请求）。
• 如果提案节点发现响应的决策节点中，已经有至少一个节点的应答中包含有值了，那它就不能够随意取值了，必须无条件地从应答中找出提案 ID 最大的那个值并接受，构成一个二元组“(id, maxAcceptValue)”，再次广播给全部的决策节点（称为 Accept 请求）。

当每一个决策节点收到 Accept 请求时，都会在不违背以前作出的承诺的前提下，接收并持久化对当前提案 ID 和提案附带的值。如果违反此前做出的承诺，即收到的提案 ID 并不是决策节点收到过的最大的，那允许直接对此 Accept 请求不予理会。

工作实例

假设一个分布式系统有五个节点，分别命名为 S₁、S₂、S₃、S₄、S₅，这个例子中只讨论正常通信的场景，不涉及网络分区。全部节点都同时扮演着提案节点和决策节点的身份。此时，有两个并发的请求分别希望将同一个值分别设定为 X（由 S₁作为提案节点提出）和 Y（由 S₅作为提案节点提出），以 P 代表准备阶段，以 A 代表批准阶段，这时候可能发生以下情况：

• 情况一：譬如，
  • S₁选定的提案 ID 是 3.1（全局唯一 ID 加上节点编号），请求设置的值是 X，先取得了多数派决策节点的 Promise 和 Accepted 应答，
  • 此时 S₅选定提案 ID 是 4.5，发起 Prepare 请求，请求设置的值是 Y。收到的多数派应答中至少会包含 1 个（必须超过半数）此前应答过 S₁的决策节点，假设是 S₃，
  • 那么 S₃提供的 Promise 中必将包含 S₁已设定好的值 X，S₅就必须无条件地用 X 代替 Y 作为自己提案的值（必须无条件地从已应答中找出提案 ID 最大的那个值并接受）
  • 由此整个系统对“取值为 X”这个事实达成一致，如图 6-2 所示。
  • 可以看出，X 被选定为最终值并不是必定需要多数派的共同批准，只取决于 S₅提案时 Promise 应答中是否已包含了批准过 X 的决策节点

• 情况二：事实上，
  • 对于情况一，X 被选定为最终值是必然结果，但从图 6-2 中可以看出，X 被选定为最终值并不是必定需要多数派的共同批准，只取决于 S₅提案时 Promise 应答中是否已包含了批准过 X 的决策节点（必须无条件地从已应答中找出提案 ID 最大的那个值并接受）
  • 譬如图 6-3 所示，S5 的提案到达的时候，X 并未获得多数派批准，但由于 S₃已经批准的关系，最终共识的结果仍然是 X。

• 情况三：当然，
  • 另外一种可能的结果是 S₅提案时 Promise 应答中并未包含批准过 X 的决策节点
  • 譬如应答 S₅提案时，节点 S₁已经批准了 X，节点 S₂、S₃未批准但返回了 Promise 应答，
  • 此时 S₅以更大的提案 ID 获得了 S₃、S₄、S₅的 Promise，这三个节点均未批准过任何值
  • 那么 S₃将不会再接收来自 S₁的 Accept 请求，因为它的提案 ID 已经不是最大的了 （S5 的提案到达的时候 S₃还没应答过 S₁ 的 P3.1提案，自然就接受最大的那个）
  • 这三个节点将批准 Y 的取值（超过半数了），整个系统最终会对“取值为 Y”达成一致，如图 6-4 所示

• 情况四：
  • 从情况三可以推导出另一种极端的情况，如果两个提案节点交替使用更大的提案 ID 使得准备阶段成功，但是批准阶段失败的话，这个过程理论上可以无限持续下去，形成活锁（Live Lock）
  • 如图 6-5 所示。在算法实现中会引入随机超时时间来避免活锁的产生。

虽然 Paxos 是以复杂著称的算法，但以上介绍都是基于 Basic Paxos、以正常流程（未出现网络分区等异常）、通俗方式讲解的 Paxos 算法，并未涉及严谨的逻辑和数学原理，也未讨论 Paxos 的推导证明过程，对于普通的不从事算法研究的技术人员来说，理解起来应该也不算太困难。

Basic Paxos 的价值在于开拓了分布式共识算法的发展思路，但它因有如下缺陷，一般不会直接用于实践：

1. Basic Paxos 只能对单个值形成决议
2. 决议的形成至少需要两次网络请求和应答（准备和批准阶段各一次），高并发情况下将产生较大的网络开销
3. 极端情况下甚至可能形成活锁。

总之，Basic Paxos 是一种很学术化但对工业化并不友好的算法，现在几乎只用来做理论研究。实际的应用都是基于 Multi Paxos 和 Fast Paxos 算法的，接下来我们将会了解 Multi Paxos 与一些它的理论等价的算法（如 Raft、ZAB 等算法）。