摘自*：分布式系统中的节点通信存在两种模型：共享内存（Shared memory）和消息传递（Messages passing）。基于消息传递通信模型的分布式系统，不可避免的会发生以下错误：进程可能会慢、垮、重启，消息可能会延迟、丢失、重复，在基础 Paxos 场景中，先不考虑可能出现消息篡改即拜占庭错误的情况。Paxos 算法解决的问题是在一个可能发生上述异常的分布式系统中如何就某个值达成一致，保证不论发生以上任何异常，都不会破坏决议的一致性。一个典型的场景是，在一个分布式数据库系统中，如果各节点的初始状态一致，每个节点都执行相同的操作序列，那么他们最后能得到一个一致的状态。为保证每个节点执行相同的命令序列，需要在每一条指令上执行一个「一致性算法」以保证每个节点看到的指令一致。一个通用的一致性算法可以应用在许多场景中，是分布式计算中的重要问题。

paxos旨在解决分布式的一致性问题。

算法划分角色描述后的问题：

1. 决议（value）只有在被 proposers 提出后才能被批准（未经批准的决议称为「提案（proposal）」）；
2. 在一次 Paxos 算法的执行实例中，只批准（chosen）一个 value；
3. learners 只能获得被批准（chosen）的 value。

理解这三个问题时，对于“一次Paxos算法”的定义比较有疑问。

批准 value 的过程中，首先 proposers 将 value 发送给 acceptors，之后 acceptors 对 value 进行接受(accept)。为了满足只批准一个 value 的约束，要求经「多数派（majority）」接受的 value 成为正式的决议（称为「批准」决议）。这是因为无论是按照人数还是按照权重划分，两组「多数派」至少有一个公共的 acceptor，如果每个 acceptor 只能接受一个 value，约束2就能保证。

然后为了保证上面3个问题，提出了约束如下：

P1：一个 acceptor 必须接受(accept)第一次收到的提案。

P2：一旦一个具有 value v 的提案被批准(chosen)，那么之后批准(chosen)的提案必须具有 value v。

P2a：一旦一个具有 value v 的提案被批准(chosen)，那么之后任何 acceptor 再次接受(accept)的提案必须具有 value v。

P2b：一旦一个具有 value v 的提案被批准(chosen)，那么以后任何 proposer 提出的提案必须具有 value v。

P2c：如果一个编号为 n 的提案具有 value v，那么存在一个多数派，要么他们中所有人都没有接受(accept)编号小于 n

的任何提案，要么他们已经接受(accept)的所有编号小于 n 的提案中编号最大的那个提案具有 value v。

如果没有接受，那么value v的提案是怎么诞生的？

算法的内容

要满足 P2c 的约束，proposer 提出一个提案前，首先要和足以形成多数派的 acceptors 进行通信，获得他们进行的最近一次接受(accept)的提案（prepare 过程），之后根据回收的信息决定这次提案的 value，形成提案开始投票。当获得多数 acceptors 接受(accept)后，提案获得批准(chosen)，由 proposer 将这个消息告知 learner。这个简略的过程经过进一步细化后就形成了 Paxos 算法。

在一个paxos实例中，每个提案需要有不同的编号，且编号间要存在全序关系。可以用多种方法实现这一点，例如将序数和 proposer 的名字拼接起来。如何做到这一点不在 Paxos 算法讨论的范围之内。

如果一个最近一次接受(accept)的提案编号为 m 的acceptor 在 prepare 过程中回答了一个 proposer 针对提案 n (n > m)的问题，但是在开始对 n 进行投票前，又接受(accept)了编号小于 n 的另一个提案（例如 n-1），如果 n-1 和 m 具有不同的 value，这个投票就会违背 P2c。因此在 prepare 过程中，acceptor 进行的回答同时也应包含承诺：不会再接受(accept)编号小于 n 的提案。这是对 P1 的加强：

P1a：当且仅当 acceptor 没有回应过编号大于 n 的 prepare 请求时，acceptor 接受(accept)编号为 n 的提案。

决议的提出与批准

通过一个决议分为两个阶段：

1. prepare 阶段：
   1. proposer 选择一个提案编号 n 并将 prepare 请求发送给 acceptors 中的一个多数派；
   2. acceptor 收到 prepare 消息后，如果提案的编号大于它已经回复的所有 prepare 消息，则 acceptor 将自己上次接受的提案回复给 proposer，并承诺不再回复小于 n 的提案；
2. 批准阶段：
   1. 当一个 proposer 收到了多数 acceptors 对 prepare 的回复后，就进入批准阶段。它要向回复 prepare 请求的 acceptors 发送 accept 请求，包括编号 n 和根据 P2c 决定的 value（如果根据 P2c 没有已经接受的 value，那么它可以*决定 value）。
   2. 在不违背自己向其他 proposer 的承诺的前提下，acceptor 收到 accept 请求后即接受这个请求。

这个过程在任何时候中断都可以保证正确性。例如如果一个 proposer 发现已经有其他 proposers 提出了编号更高的提案，则有必要中断这个过程。因此为了优化，在上述 prepare 过程中，如果一个 acceptor 发现存在一个更高编号的提案，则需要通知 proposer，提醒其中断这次提案。