深入浅出Paxos协议

Posted 2021-04-17 大型网站架构知识图谱

前言

Paxos协议几乎是分布式领域内一致性协议的代名词。Chubby的开发者曾经说过：“所有的一致性协议本质上要么是Paxos，要么是其变体。”。本篇将首先介绍多副本状态机模型，然后描述协议本身内容与协议流程，最后以一个例子收尾。更多资料及详细的数学证明请参考wiki。

一种应用场景介绍-副本状态机模型

一种典型的应用场景，集群中的多台服务器各自保存一份log副本和内部状态机，log内顺序记载客户端的操作指令，为了保持每个服务器内部状态机的一致，需要在各个服务器的log对应某个固定位置的操作命令达成一致。而这种达成一致的阻碍是：某一个时刻，不同服务器的log相同位置的操作命令是不一致的。而Paxos就是这样一种协议：对于各个服务器log的固定位置，能保证在有限时间内达成一致意见，即每个服务器的log内容顺序是一致的。对于要求一致性的场景，此为一种抽象化表述。

协议流程

Paxos将系统中的角色分为提议者 (Proposer)，决策者 (Acceptor)，和学习者 (Learner)，在多副本状态机中，每个副本同时具有Proposer、Acceptor、Learner三种角色。

• Proposer: 提出提案 (Proposal)。Proposal信息包括提案编号 (Proposal ID) 和提议的值 (Value)。

• Acceptor：参与决策，回应Proposers的提案。收到Proposal后可以接受提案，若Proposal获得多数Acceptors的接受，则称该Proposal被批准。

• Learner：不参与决策，从Proposers/Acceptors学习最新达成一致的提案（Value）。

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

第一阶段：Prepare阶段。Proposer向Acceptors发出Prepare请求，Acceptors针对收到的Prepare请求进行Promise承诺。

第二阶段：Accept阶段。Proposer收到多数Acceptors承诺的Promise后，向Acceptors发出Propose请求，Acceptors针对收到的Propose请求进行Accept处理。

Paxos算法流程中的每条消息描述如下：

• Prepare: Proposer生成全局唯一且递增的Proposal ID (可使用时间戳加Server ID)，向所有Acceptors发送Prepare请求。

• Promise: Acceptors收到Prepare请求后，做出“两个承诺，一个应答”。

  两个承诺：

• 1. 不再接受Proposal ID小于等于当前请求的Prepare请求。

• 2. 不再接受Proposal ID小于当前请求的Propose请求。

  一个应答：

• 不违背以前作出的承诺下，回复已经Accept过的提案中Proposal ID最大的那个提案的Value和Proposal ID，没有则返回空值。

• Propose: Proposer 收到多数Acceptors的Promise应答后，从应答中选择Proposal ID最大的提案的Value，作为本次要发起的提案。然后携带当前Proposal ID，向所有Acceptors发送Propose请求。

• Accept: Acceptor收到Propose请求后，在不违背自己之前作出的承诺下，接受并持久化当前Proposal ID和提案Value。

• Learn: Proposer收到多数Acceptors的Accept后，决议形成，将形成的决议发送给所有Learners。

一个例子

下图演示了两个 Proposer（提案者） 和三个 Acceptor（附议者） 的系统中运行该算法的过程，每个 Proposer 都会向所有 Acceptor 发送提议请求。提议包含两个字段：[n, v]，其中 n 为序号（Proposal ID），v 为提议值。

当 Acceptor 接收到一个提议请求，包含的提议为 [n1, v1]，并且之前还未接收过提议请求，那么发送一个提议响应，设置当前接收到的提议为 [n1, v1]，并且保证以后不会再接受序号小于 n1 的提议。

如下图，Acceptor X 在收到 [n=2, v=8] 的提议请求时，由于之前没有接收过提议，因此就发送一个尚无提案的提议响应，并且设置当前接收到的提议为 [n=2, v=8]，并且保证以后不会再接受序号小于 2 的提议。其它的 Acceptor 类似。

如果 Acceptor 接收到一个提议请求，包含的提议为 [n2, v2]，并且之前已经接收过提议 [n1, v1]。如果 n1 > n2，那么就丢弃该提议请求；否则，发送提议响应，该提议响应包含之前已经接收过的提议 [n1, v1]，设置当前接收到的提议为 [n2, v2]，并且保证以后不会再接受序号小于 n2 的提议。

如下图，Acceptor Z 收到 Proposer A 发来的 [n=2, v=8] 的提议请求，由于之前已经接收过 [n=4, v=5] 的提议，并且 n > 2，因此就抛弃该提议请求；Acceptor X 收到 Proposer B 发来的 [n=4, v=5] 的提议请求，因为之前接收到的提议为 [n=2, v=8]，并且 2 <= 4，因此就发送 [n=2, v=8] 的提议响应，设置当前接收到的提议为 [n=4, v=5]，并且保证以后不会再接受序号小于 4 的提议。Acceptor Y 类似。

当一个 Proposer 接收到超过一半 Acceptor 的提议响应时，就可以发送接受请求。

Proposer A 接收到两个提议响应之后，就发送 [n=2, v=8] 接受请求。该接受请求会被所有 Acceptor 丢弃，因为此时所有 Acceptor 都保证不接受序号小于 4 的提议。

Proposer B 过后也收到了两个提议响应，因此也开始发送接受请求。需要注意的是，接受请求的 v 需要取accepter返回值。因此它发送 [n=4, v=8] 的接受请求。

Acceptor 接收到接受请求时，如果序号大于等于该 Acceptor 承诺的最小序号，那么就对当前值做accept操作。当 proposer发现有大多数的 Acceptor 接收了某个提议，那么该提议的提议值就被 Paxos 选择出来。