分布式一致性算法Paxos

引言

        Paxos算法是Lamport宗师提出的一种基于消息传递的分布式一致性算法，是目前公认的解决分布式一致性问题最有效的算法之一。Google Chubby的作者Mike Burrows曾经狂妄的说过这个世界上只有一种一致性算法，那就是Paxos，其它的算法都是残次品。

        Paxos算法是一种理念，你可以在很多分布式系统的设计中看到它的影子，例如在分布式锁、主从复制、命名服务、分布式协调等常见场景下，Paxos算法都有着广泛的应用。

什么是分布式一致性

        分布式一致性是指在分布式系统中，多个节点对同一份数据进行修改或读取时，保证这些操作所产生的结果都是相同的。在实际应用中，由于网络延迟、节点崩溃等因素的存在，可能会导致不同节点的数据副本出现不一致的情况。因此，分布式一致性成为了分布式系统设计中一个非常重要的问题。

        例如，考虑一个在线购物网站的场景，该网站使用分布式系统处理订单和库存信息。当一个用户下单时，该订单会被写入多个节点的数据库中并同时减少相应商品的库存数量。由于数据需要在节点之间进行复制以提高可用性和性能，如果某个节点上的订单状态与另一个节点不同步，则可能导致错误的商品数量被减少，从而导致库存错误。

        Paxos 算法主要就是解决如何在一个可能发生故障的分布式系统中，快速正确的在集群内对某个值达成一致，并且保证整个系统的一致性。

Quorum 机制

        学习Paxos算法之前需要先了解分布式系统中的一个选举算法Quorum，Quorum算法会在Paxos算法中出现。Quorum 选举算法的主要数学思想来源于抽屉原理：“如果每个格子代表一个集合，每一个格子就可以代表一个元素，假如有n+1个元素放到n个集合中去，其中必定有一个集合里至少有两个元素。” 应用到分布式领域可以解释为，在 N 个副本中，一次更新成功的如果有 W 个，那么我在读取数据时是要从大于 N－W 个副本中读取，这样才能至少读到一个更新的数据了。

        和 Quorum 机制对应的是 WARO(Write All Read one)，是一种简单的副本控制协议，当 Client 请求向某副本写数据时，只有当所有的副本都更新成功之后，这次写操作才算成功，否则视为失败。 WARO 优先保证读服务，因为所有的副本更新成功，才能视为更新成功，从而保证了所有的副本一致，这样的话，只需要读任何一个副本上的数据即可。但是写服务的可用性较低，因为只要有一个副本更新失败，此次写操作就视为失败了。

        Quorum 机制无法保证强一致性，也就是无法实现任何时刻任何用户或节点都可以读到最近一次成功提交的副本数据。Quorum 是分布式系统中常用的一种机制，用来保证数据冗余和最终一致性的投票算法，在 Paxos、Raft 和 ZooKeeper 的 Zab 等算法中，都可以看到 Quorum 机制的应用。

算法描述 

角色划分

        Paxos将系统中的角色分为提议者 (Proposer)，决策者 (Acceptor)，和最终决策学习者 (Learner)。

 Proposer 提案者

        提案者负责提出提案 (Proposal)，Proposal信息包括提案编号 (Proposal ID) 和提议的值 (Value)。所谓提案的value，在实际项目中可以是任何操作，比如“将A的值从0改为1”，Paxos 协议中统一将这些操作抽象为value。Proposer可以有多个，不同的Proposer可以提出不同的甚至矛盾的value，比如提案者A提议“将变量X设置为0”，另一个提案者B提议“将变量X设置为2”，但对同一轮Paxose而言，最多只有一个value可以被批准。

Acceptor 批准者

        接受者可以对提议者提出的提议进行投票表决，接受者之间是完全独立的。提议有超过半数的接受者投票批准即被选中，接受提案后提案里面的value就选定了。

Learner 学习者

        Learner 不参与选举，而是学习被批准的 value，在Paxos中，Learner主要参与相关的状态机同步流程。这里Leaner的流程就参考了Quorum议会机制，某个value需要获得超过半数的Acceptor 批准，Learner需要至少读取 N/2+1个Accpetor，最多读取 N个Acceptor的结果后，才能学习到一个通过的value。

算法流程

决议的提出与批准

prepare阶段：

Proposer： Proposer生成全局唯一且递增的提案编号N，向所有Acceptor发送Prepare请求，这里无需携带提案内容，只携带提案编号即可, 即发送 Proposer(N, null)。

Acceptor： Acceptor收到Prepare请求后，有两种情况：

1. 如果Acceptor首次接收Prepare请求, 设置MaxN=N， 同时响应ok

2. 如果Acceptor不是首次接收Prepare请求，则：

• 若请求过来的提案编号N小于等于上次持久化的提案编号ResN，则不响应或者响应error。

• 若请求过来的提案编号N大于上次持久化的提案编号MaxN, 则更新MaxN=N，同时给出响应。响应的结果有两种：

  • 如果这个Acceptor此前没有接受过提案，只返回ok，并承诺不再回复小于N的提案。

  • 如果这个Acceptor此前接收过提案，则返回ok和上次接受的提案编号AcceptN, 接收的提案AcceptV。

批准阶段

为了方便描述，我们把 Phase 2 选举阶段继续拆分为 P2a、P2b 和 P2c。

P2a：Proposer接收Accept消息，发送Accept

经过一段时间后，Proposer 收集到一些Prepare阶段的回复，有下列几种情况：

• 若回复数量 > 一半的 Acceptor 数量，且所有回复的 value 都为空时，则 Porposer 发出 accept 请求，并带上自己指定的提案value。

• 若回复数量 > 一半的 Acceptor 数量，且有的回复 value 不为空时，则 Porposer 发出 accept 请求，并挑选出回复中提案号最大的提案，取出提案的value作为自己的提案内容。

• 若回复数量 <= 一半的 Acceptor 数量时，则重新尝试更新生成更大的提案号N，再转到准备阶段执行。

P2b：Acceptor 应答 Accept

Accpetor 收到 Accpet 请求后，判断：

• 若收到的提案号N >= MaxN（一般情况下是等于），则回复提交成功，并持久化N和value，接受提案；

• 若收到的 N < MaxN，则不回复或者回复提交失败，不接受提案。

P2c: Proposer 统计投票

经过一段时间后，Proposer 会收集到一些 Accept 回复提交成功的情况，比如：

• 当回复数量 > 一半的 Acceptor 数量时，则表示提交 value 成功，此时可以发一个广播给所有的 Proposer、Learner，通知它们已提交的 value；

• 当回复数量 <= 一半的 Acceptor 数量时，则尝试更新生成更大的提案号，转到准备阶段执行。

• 当收到一条提交失败的回复时，则尝试更新生成更大的提案号，也会转到准备阶段执行。

学习阶段

Proposer收到多数Acceptor的Accept后，决议形成，将形成的决议发送给所有Learner，Learner进行学习。

举例说明

 

上面的算法确实不太好理解，下面引用一个维基百科的例子来理解一下。

降低税率

        有A1, A2, A3, A4, A5 5位议员，就税率问题进行决议。议员A1决定降税率,因此它向所有人发出一个草案。这个草案的内容是：

        现有的税率是什么?如果没有决定，我来决定一下。提出时间：本届议会第3年3月15日;提案者：A1

        在最简单的情况下，没有人与其竞争；信息能及时顺利地传达到其它议员处。于是, A2-A5回应：

        我已收到你的提案，等待最终批准。

        而A1在收到3份回复后(超过一半)就发布最终决议：税率已定为10%，新的提案不得再讨论本问题。

        这实际上退化为二阶段提交协议。

场景升级

        现在我们假设在A1提出提案的同时, A5也提出提案决定将税率定为20%：

        现有的税率是什么?如果没有决定，我来决定一下商议时间：本届议会第3年3月16日，提案者：A5

        草案要通过侍从送到其它议员的案头。A1的草案将由4位侍从送到A2-A5那里。现在，负责A2和A3的侍从将草案顺利送达，负责A4和A5的侍从则不上班，A5的草案则顺利的送至A3和A4手中。

        现在, A1, A2, A3收到了A1的提案; A3, A4, A5收到了A5的提案。按照协议, A1, A2, A4, A5准备接受他们收到的提案，侍从将拿着 『我已收到你的提案，等待最终批准。』的回复回到提案者那里。

        那么最终A3的行为将决定批准哪一个。

        在讨论之前我们要明确一点，提案是全局有序的。在这个示例中，是说每个提案提出的日期都不一样。即第3年3月15日只有A1的提案；第3年3月16日只有A5的提案，不可能在某一天存在两个提案。

情况1

        假设A1的提案先送到A3处，而A5的侍从决定放假一段时间。于是A3接受并派出了侍从。A1等到了两位侍从，加上它自己已经构成一个多数派，于是税率10%将成为决议。A1派出侍从将决议送到所有议员处：

        税率已定为10%，新的提案不得再讨论本问题。

        A3在很久以后收到了来自A5的提案。由于税率问题已经讨论完毕，开始讨论某些议员在第3年3月17日提出的议案。因此这个3月16日提出的议案他不去理会。他自言自语地抱怨一句：

        这都是老问题了，没有必要讨论了。

 情况2

        依然假设A1的提案先送到A3处，但是这次A5的侍从不是放假了，只是中途耽搁了一会。这次, A3依然会将"接受"回复给A1.但是在决议成型之前它又收到了A5的提案。则：

1.如果A5提案的提出时间比A1的提案更晚一些，这里确实满足这种情况，因为3月16日晚于3月15日。则A3回复：

        我已收到您的提案，等待最终批准，但是您之前有人提出将税率定为10%,请明察。

于是, A1和A5都收到了足够的回复。这时关于税率问题就有两个提案在同时进行。但是A5知道之前有人提出税率为10%。于是A1和A5都会向全体议员广播：

        税率已定为10%,新的提案不得再讨论本问题。

共识到了保证。

2. 如果A5提案的提出时间比A1的提案更早一些。假设A5的提案是3月14日提出，则A3直接不理会。

        A1不久后就会广播税率定为10%

应用

        Zookeeper使用一个类Multi-Paxos的共识算法作为底层存储协同的机制。

        Google公司在其分布式锁中应用了Multi-Paxos算法。