分布式系统（2)——Paxos算法-CFANZ编程社区

Paxos、Raft分布式一致性算法应用场景

如果想要掌握Paxos算法和Raft算法，必须了解分布式一致性问题与分布式一致性算法的典型应用场景。

分布式一致性问题：一个或多个线程提议一个值应当是什么之后，使系统中所有的进程对这个达成一致意见。

举个栗子：

领导者选举问题（leader election）：进程对leader达成一致；

互斥（mutual exclusion)：进程对进入临界区的进程达成一致；

原子广播（atomic broadcast）：进程对消息传递顺序达成一致；

分布式一致性问题的定义如图所示：

为了达成一致，每个进程都提出自己的提议（propose），最终通过分布式一致性算法，所有正确允许的进程决定（decide）相同的值。

但是分布式系统是基于消息传递的异步分布式系统，进程可能会出现各种问题，在一个可能发生异常的分布式系统中如何就某个值达成一致，如何发生上述哪一种异常都不会破坏决议的一致性。

分布式一致性算法的典型应用场景：

使用多副本的方式实现容错，每一份数据都保存多个副本，这样副本的失效不会导致数据的丢失，每次更新操作都要更新数据的所有副本，以便让多个副本的数据保持一致，如何在一个可能出现故障的异步分布式系统实现多个副本的Consistency一致性呢？

①主从同步复制——写请求首先发送给主副本，主副本同步更新到其他副本后返回，保证强一致性

强一致性(Consistency）到位但是可用性（Available）差，看图就很好理解只要任意一个副本写失败，写请求将执行失败

②主从异步复制，主副本写成功后立即返回，然后再后台更新其他的副本，与上一个正好相反，可用性（Available）好，但是强一致性（Consistency）无法得到保证。

同步复制为最高保护模式（Maximum Protection），异步复制为最高性能模式（Maximum Performance），还有一种最高可用性模式（Maximum Availability）介于两者之间，在正常情况下，它和最高保护模式一样，但一旦同步出现故障，切换成最高性能模式。

传统的主从同步或者主从异步，无法同时保证数据的一致性和可用性，前文说过的CAP理论也可以证明这个问题。

这时候平衡主义者就要站出来说，为什么不能在一致性和可用性之间进行平衡？这就引出了我们所说的Paxos和Raft等分布式一致性算法，在一致性和可用性之间取得很好的平衡，在保证一定的可用性的同时，能够对外提供强一致性，因此Paxos、Raft等分布式一致性算法被广泛的用于管理副本的一致性，提供高可用性。

一、Paxos算法背景

Paxos算法是Lamport宗师提出的一种基于消息传递的分布式一致性算法，使其获得2013年图灵奖。

Paxos由Lamport于1998年在《The Part-Time Parliament》论文中首次公开，最初的描述使用希腊的一个小岛Paxos作为比喻，描述了Paxos小岛中通过决议的流程，并以此命名这个算法，但是这个描述理解起来比较有挑战性。后来在2001年，Lamport觉得同行不能理解他的幽默感，于是重新发表了朴实的算法描述版本《Paxos Made Simple》。

自Paxos问世以来就持续垄断了分布式一致性算法，Paxos这个名词几乎等同于分布式一致性。Google的很多大型分布式系统都采用了Paxos算法来解决分布式一致性问题，如Chubby、Megastore以及Spanner等。开源的ZooKeeper，以及MySQL 5.7推出的用来取代传统的主从复制的MySQL Group Replication等纷纷采用Paxos算法解决分布式一致性问题。

然而，Paxos的最大特点就是难，不仅难以理解，更难以实现。

二、Paxos算法流程

Paxos算法解决的问题正是分布式一致性问题，即一个分布式系统中的各个进程如何就某个值（决议）达成一致。

Paxos算法运行在允许宕机故障的异步系统中，不要求可靠的消息传递，可容忍消息丢失、延迟、乱序以及重复。它利用大多数 (Majority) 机制保证了2F+1的容错能力，即2F+1个节点的系统最多允许F个节点同时出现故障。

一个或多个提议进程 (Proposer) 可以发起提案 (Proposal)，Paxos算法使所有提案中的某一个提案，在所有进程中达成一致。系统中的多数派同时认可该提案，即达成了一致。最多只针对一个确定的提案达成一致。

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

Proposer: 提出提案 (Proposal)。Proposal信息包括提案编号 (Proposal ID) 和提议的值 (Value)。
Acceptor：参与决策，回应Proposers的提案。收到Proposal后可以接受提案，若Proposal获得多数Acceptors的接受，则称该Proposal被批准。
Learner：不参与决策，从Proposers/Acceptors学习最新达成一致的提案（Value）。

在多副本状态机中，每个副本同时具有Proposer、Acceptor、Learner三种角色。

Paxos算法中的角色

Paxos算法通过一个决议分为两个阶段（Learn阶段之前决议已经形成）：

第一阶段：Prepare阶段。Proposer向Acceptors发出Prepare请求，Acceptors针对收到的Prepare请求进行Promise承诺。
第二阶段：Accept阶段。Proposer收到多数Acceptors承诺的Promise后，向Acceptors发出Propose请求，Acceptors针对收到的Propose请求进行Accept处理。
第三阶段：Learn阶段。Proposer在收到多数Acceptors的Accept之后，标志着本次Accept成功，决议形成，将形成的决议发送给所有Learners。

在具体实现中，一个进程可能同时充当多种角色，比如一个进程可能既是Proposer又是Acceptor又是Learner。 Proposal理解为提案，最终要求达成一致的value就在提案里（可用暂时认为提案=value），对数据的某个值Value达成一致，指的是Proposer、Acceptor、Learner都认为同一个value被选定（chosen），那么Proposer、Acceptor、Learner分别在什么情况下认为value被选定呢？

1.Proposer：Proposer发的提案被Acceptor接受（半数以上Acceptor同意），则认为value被选定。

2.Acceptor：只有Acceptor接受每个提案，Acceptor就任务该提案中的value被选定。

3.Learner：Acceptor告诉哪个value被选定，Learner认为哪个value被选定。

问题描述：

假设有一组可以提出（propose）value（value在提案Proposal里）的进程集合。一个一致性算法需要保证提出的这么多value中，只有一个value被选定（chosen）。如果没有value被提出，就不应该有value被选定。如果一个value被选定，那么所有进程都应该能学习（learn）到这个被选定的value。对于一致性算法，安全性（safaty）要求如下：

只有被提出的value才能被选定。
只有一个value被选定，并且
如果某个进程认为某个value被选定了，那么这个value必须是真的被选定的那个。

我们不去精确地定义其活性（liveness）要求。我们的目标是保证最终有一个提出的value被选定。当一个value被选定后，进程最终也能学习到这个value。

假设不同角色之间可以通过发送消息来进行通信，那么：

每个角色以任意的速度执行，可能因出错而停止，也可能会重启。一个value被选定后，所有的角色可能失败然后重启，除非那些失败后重启的角色能记录某些信息，否则等他们重启后无法确定被选定的值。
消息在传递过程中可能出现任意时长的延迟，可能会重复，也可能丢失。但是消息不会被损坏，即消息内容不会被篡改（拜占庭将军问题）。

三.Paxos算法描述

阶段一：

（a）： Proposer选择一个提案编号N，然后向半数以上的Acceptor发送编号为N的Prepare请求。

（b）：如果一个Acceptor收到一个编号为N的Prepare请求，且N大于该Acceptor已经响应过的所有Prepare请求的编号，那么它就会将它已经接受过的编号最大的提案（如果有的话）作为响应反馈给Proposer，同时该Acceptor承诺不再接受任何编号小于N的提案。

阶段二：

（a）：如果Proposer收到半数以上Acceptor对其发出的编号为N的Prepare请求的响应，那么它就会发送一个针对[N,V]提案的Accept请求给半数以上的Acceptor。注意：V就是收到的响应中编号最大的提案的value，如果响应中不包含任何提案，那么V就由Proposer自己决定。

（b）：如果Acceptor收到一个针对编号为N的提案的Accept请求，只要该Acceptor没有对编号大于N的Prepare请求做出过响应，它就接受该提案。