一文看懂Paxos和Raft算法

Posted 2021-04-17 一切都是浮云计算

Paxos是consensus(共识)算法的鼻祖，Raft可以认为是改良过的共识算法。

共识是啥？

如果对区块链有所了解，对于“共识”一定不会陌生。本文只介绍Paxos和Raft。

一致性是一个难题

分布式系统的环境里，保持写一致并非易事。比如说一个分布式的数据库系统，由很多 节点组成，每个节点都有副本。系统的一致性可以理解为满足要求如下：

• 任意一个节点收到读请求，都能获得一样的信息；

• 任意一个节点收到写要求，都能更新所有的节点副本。

举一个现实的例子：某个地方的法律由一个民主委员会负责维护和更新，法律由成员投票民主表决。可喜的是，委员会的成员都绝对正派：

• 每个成员都靠谱，新提案都经过深思熟虑，一般都会收到其他成员的支持，除非是无脑建议，那么一定会收到所有其他成员的否决（注：这个反人性的假设是为了模仿计算机）；

• 任何人随便问其中一个委员会成员关于法律的具体问题，都能得到一致的如实回答（读操作一致）；

• 新法律经过特定流程表决通过后，每个委员会成员都会及时更新法律认知（写操作一致）。

下面说“但是”了。这个地方的民主程度相当高，鼓励各行各业有识之士参与（哎哟不错哦，这个好像很先进嘛）

• 这样就无法保证每个繁忙成员在每次投票的时候都能及时给出回复（相当于临时宕机了，要重启）；

• 各成员不是在一个办公室里工作，都是单独收发信息（古代就是派信使），可以给任何人发出信息，虽然不保证对方能及时回复（真实的计算机世界的分布式环境就是这般景象）。

下面要解决问题：每个成员都可以提议更新法律，也可能同时有多名成员提出互相冲突的提案，但一次只有一个提案可以通过（当然，可以提多次）。那么，如何制定规范的法律表决过程，让法律提案能顺利走完民主程序，无论通过或否决（写操作一致）。

温馨提醒：如果以文史、政治、人性等角度去思考这个问题，那定会被其反常性的细节所扰，自取烦恼，而应该以计算机和数学的角度去理解，一切比喻都只是为了叙述。

敝人废话那么多，只为博君一笑，“哦！！！原来这就是Paxos所要解决的分布式计算问题！”

以上故事改编自赫赫有名的Leslie Lamport（LaTeX中的La）的论文The Part-Time Parliament （ http://research.microsoft.com/users/lamport/pubs/lamport-paxos.pdf ）就是这篇论文提出了Paxos算法。为什么叫Paxos？Paxos是希腊的小岛，这么有希腊文化和人文气息的幽默感，在计算机科学世界却并未得到专家的共识，一定程度上也增加了理解的复杂度（建议去浏览一下论文原文，再评论）。后来Lamport又写了篇中规中矩的计算机论文，简短很多，Paxos Made Simple http://lamport.azurewebsites.net/pubs/paxos-simple.pdf

经典算法假设不存在拜占庭错误，就是说没有节点会造假，就是委员会每个成员都很正派，没有内奸。嗯，拜占庭？啊？又是个这么有人文气息的名字？So what? 数学系也出诗人啊。具体拜占庭错误详见这篇计算机版的《潜伏》，，烧脑勿进。。。

现今Paxos岛何在？

哇，看着像神往的旅游胜地啊

以上来自Google map和image。

Poxas算法解读

Paxos的问题提出稍显纠结，不错算法思路蛮简单直接的。直接讲重点，首先分关键角色：Proposer（提出提案者）, Acceptor（审批提案者）。

算法过程分2步：

1. 准备阶段：Proposer将提案发给其他成员(Acceptor)，Acceptor如果同时收到多个提案，则根据事先约定的编号规则选取一个提案，对选中的提案Proposer回复yes，剩余的提案Proposer们回复no。

2. 批准阶段：Proposer收到Acceptor们的回复后，如果多数通过则回复accept，Acceptor收到此accept确认回复，就正式批准提案。

如果一次只有一个提案，那上述过程非常简单。分布式计算要处理的是，短时间内同时有很多提案，且网络会通讯中断的情况。

几个关键：

• 成员编号规则：每个成员都会有一个独一的ID，如果Acceptor收到多位Proposer们的提案，比如：126说闯红灯罚500块，139说闯红灯罚600块，则ID大的139的提案胜出。每位Proposer都遵守这个规则，因此都能获得一致的决定。编号的生成方式本身不在Paxos算法范围内，可以灵活处理，比如：每次提案表决后，都重新生成编号。

• 提案编号规则：每条法律都有明确编号，所有表决前，每个成员都有所有法律信息，每次新提案都会产生新编号，新编号和提案一起发出审批。如果某Proposer因网络故障，可能当Acceptor收到的时候，已经完成该轮表决，而已经在处理下一轮时，则根据编号就可以否决这条延时的老提案。

• 民主多数通过：如果Proposer因网络故障没收到足够回复，则本次提案会被取消（写操作出错）。多数通过能确保不会有平局的出现。本轮提案表决被取消后，还可以下轮重试。因此，Paxos在理论上并不保证提案一定能通过。

算法里还有个角色叫Learner，就是批准阶段结束后，新提案结果被传递给成员，这些收到结果通知的都叫Learner。Learner也是灵活设置，可以是其中几个成员，再Learner们把通知传给周围的成员。Paxos并未提供Learner相关的系统实现细节，敝人认为Learner不是算法重点，点到为止。

靓丽的状态机

Paxos算法是理论级别的，离现实系统还差较多技术细节。Paxos Made Simple中描述了状态机，作为Paxos算法的实现。

状态机由以下组成：

• 每条通过的提案都是操作指令，因此提案表决过程（即上述算法过程）就是在产生新操作指令，提案未通过则不会有新操作指令产生，对系统无影响；

• 分布式系统里的每个节点都是一个状态机；

• 任何一台状态机，如果初始状态相同，按序执行相同的指令集，得到的结果状态也相同。

因此，如果节点失联，恢复后可以同步新操作指令，则状态机又可以达到同步的状态。

Raft算法解读

Raft由Stanford的Diego Ongaro和John Ousterhout与2013年提出，论文是In Search of an Understandable Consensus Algorithm ( https://raft.github.io/raft.pdf )

直接讲重点：Raft也是基于状态机，由Log副本生成操作指令决定节点状态；节点的主要角色是Leader、Follower和Candidate。

• 为了避免如Paxos这样多Proposer同时发起不同提案，Raft先选出Leader，然后Leader负责更新状态，确保所有Follower收到一样的操作指令，从而达到一样的状态。

• 正常情况下Leader接受外部请求，传递给Follower，Follower接受Leader的新指令，很和谐。

• Follower会一直和Leader联系(heart beat)，如果规定时间内无法联系上Leader，即认为Leader失联已宕机，作为Candidiate角色(候选人)发起新一轮选举，其他节点收到后会及时回复支持新Candidate，新Term(任期)开始，选举过程结束Candidate转成Leader角色，而前Leader节点恢复后同步Log，变成这次Term里的Follower。

• 其他相对容易理解和处理，比如换Term时的config切换，增删节点，Log append-only等等。

• 上述算法过程基于前提：节点直接通讯时间(RPC) << 选举过程总时间 << 两次宕机的时间间隔，这个是实际系统中很常见的客观条件，没毛病。

温馨提醒：切莫从政治斗争或宫斗大戏的角度去理解这个选举过程，比如某节点在选举时投反对票而自己作为Candidate再要求选举？拜托，这个是无比高尚的计算节点的世界，每个节点都挺身而出冲向碉堡堵枪眼(变成Leader接受并处理外部请求)，其他节点作为Follower紧跟其后传内力，然后，一个Leader倒下，又一个站起来！

（内力图来自网络）

其他共识算法

Viewstamped Replication，第一版比Paxos还早，后来更新版和Raft差不多时间，也有些相似之处。

基于replicated state machines思想的Chubby和ZooKeeper，Raft论文是这么评价的：

The two best-known implementations of replicated state machines are Chubby [1, 2] and ZooKeeper [6, 7]. Chubby’s consensus algorithm is based on Paxos but appears to have some similarities to Raft, including a master replica (similar to a leader) and epochs (similar to terms); the details of its algorithm have not been published. ZooKeeper’s consensus mechanism, Zab, has been published in more detail [7]. It uses epochs in a fashion similar to Raft terms, and it employs a leader. Zab is designed to operate across a broader state space than Raft (e.g., a new leader can be elected without storing all of the committed entries), but these generalizations add to its complexity. Zab does not include a mechanism for cluster reconfiguration.