【分布式】共识算法：Paxos和Raft

目录

一、Paxos 算法

1. Basic Paxos 算法

2. Multi-Paxos 思想

二、Raft算法

1. 领导人选举（Leader Election）

2. 日志复制（Log Replication）

3. 安全性（Safety）

---

一、Paxos 算法

Paxos 算法是 在 1990 年提出，是第一个被证明完备的共识算法（前提是不存在拜占庭将军问题，也就是没有恶意节点）。

Paxos 算法主要包含 2 个部分：

• Basic Paxos 算法 ： 多节点之间如何就某个值（提案 Value）达成共识。
• Multi-Paxos 思想 ： 执行多个 Basic Paxos 实例，就一系列值达成共识。Multi-Paxos 说白了就是执行多次 Basic Paxos ，核心还是 Basic Paxos 。

1. Basic Paxos 算法

Basic Paxos 中存在 3 个重要的角色，这些角色只是在不同时间下，逻辑上的划分，实际上任何一个节点都可以充当这3个角色之一。

• 提议者（Proposer）：负责接受客户端发起的提议，然后尝试让接受者接受该提议，同时保证即使多个提议者的提议之间产生了冲突，那么算法都能进行下去。
• 接受者（Acceptor）：负责对提议者的提议投票，同时需要记住自己的投票历史。
• 学习者（Learner）：如果有超过半数接受者就某个提议达成了共识，那么学习者就需要接受这个提议，并就该提议作出运算，然后将运算结果返回给客户端。

2. Multi-Paxos 思想

Multi-Paxos 只是一种思想，这种思想的核心就是通过多个 Basic Paxos 实例就一系列值达成共识。

由于 Paxos 算法在国际上被公认的非常难以理解和实现，因此不断有人尝试简化这一算法。到了2013 年才诞生了一个比 Paxos 算法更易理解和实现的共识算法——Raft算法 。更具体点来说，Raft 是Multi-Paxos的一个变种，其简化了 Multi-Paxos 的思想，变得更容易被理解以及工程实现。

Paxos 算法的详解可以参考：《分布式共识算法之Paxos详解》

二、Raft算法

Raft算法 是一种更为简单方便易于理解的分布式算法，主要解决了分布式中的一致性问题。相比传统的 Paxos 算法，Raft 算法将大量的计算问题分解成为了一些简单的相对独立的子问题，并有着和 Multi-Paxos 同样的性能。

• 领导人（Leader）：由群众投票选举得出，每次选举只能选出一名领导人。领导人负责发起心跳，响应客户端，创建日志，同步日志。

• 候选人（Candidate）：当没有领导人时，某些群众可以成为候选人参与竞选领导人。候选人是领导人选举过程中的临时角色。

• 群众（Follower）：除了领导人或者候选人，其他节点都是群众。群众不会发送任何请求，只是响应来自领导人和候选人的请求，负责接受领导人的心跳和日志同步数据，投票给候选人。

为了简化逻辑和实现，Raft 算法将一致性问题分解成了三个相对独立的子问题：

• 领导人选举（Leader Election）：当领导人节点宕机或者集群初创时，一个新的领导人需要被选举出来。
• 日志复制（Log Replication）：领导人接收来自客户端的请求并将其以日志条目的形式复制到集群中的其它节点，并且强制要求其它节点的日志和自己保持一致。
• 安全性（Safety）：如果有任何节点已经应用了一个确定的日志条目到它的状态机中，那么其它节点不能在同一个日志索引位置应用一个不同的指令。

1. 领导人选举（Leader Election）

当群众（Follower）超时未收到领导人（Leader）的心跳时，群众会成为候选人（Candidate），候选人会发起投票中竞选领导人。

（1）每个群众节点有一个10~500ms随机的超时时间，当某个群众节点最先超时，这时它就成为候选人。大多数情况下不会出现相同的随机时间，只有一个候选人。但是当出现多个候选人时，两个候选人都会发起投票。如果票数不同，最先得到大部分投票的候选人会成为领导人；如果票数相同，会重新发起新一轮的投票。

（2）每个候选人发起投票，群众投票给候选人。当某个候选人获得半数以上投票后，就竞选成功成为领导人，其他候选人会转换为群众。

（3）领导人需要周期性地向群众发起心跳，当群众收到领导人的心跳后，群众的超时时间会重置为0，重新计时。领导人发起心跳的周期必须要短于群众的超时时间，一般为0.5-20ms，否则群众会频繁成为候选人，也就会出现频繁发生选举，切换领导人的情况。

任期（Term）是一个递增的连续数字，每一次任期的开始都是一次领导人选举。

如图所示，Raft 算法将时间划分为任意长度的任期。每一个任期的开始都是一次选举，如果没有选出领导人，将会开启下一个任期，并立刻开始下一次选举。Raft算法保证在给定的一个任期最多有一个领导人。

每个节点都会存储当前的任期，即term号。

（1）当节点之间进行通信时它们会交换term号，如果一个节点发现自己的term号比另一个节点小，那么它会更新为较大的term号。

（2）如果一个候选人或者领导人节点发现自己的term过期了，则该节点退回成群众；如果一个节点收到的请求的term号是过期的，那么它会拒绝该请求。

2. 日志复制（Log Replication）

在选出了领导人（Leader）之后，它就开始接受客户端的请求。每一个客户端的请求都包含一条需要被复制状态机执行的命令。

（1）领导人收到客户端请求后，会生成一个日志条目（entry），再将这个日志条目添加到自己的日志末尾后，向所有的节点广播该日志条目，要求其他节点复制这条日志条目。

（2）如果群众接受该日志条目，则会将日志条目添加到自己的日志后面，同时返回给领导人同意。

（3）如果领导人收到了半数以上的成功响应，领导人会将这个日志条目应用到自己的状态机中，并将这个日志条目标记为可被提交的，最后向客户端返回执行结果。

日志条目（entry），包含

• 索引（Index）：该条目在日志文件中的槽位。
• 任期号（Term）：用于检测在不同节点上日志的不一致问题。
• 指令（Command）：用于被状态机执行的外部命令。

3. 安全性（Safety）

然而，到目前为止描述的机制还不足以确保每个状态机以相同的顺序执行完全相同的命令，例如当 领导人（Leader） 提交多个日志条目（entry）时，群众（Follower）可能不可用，然后它可以被选为看得人并用新的条目覆盖这些条目； 因此，不同的状态机可能会执行不同的指令序列。

通过添加对哪些节点可以被选为领导人的限制，来确保任何给定任期的领导人都包含之前任期中提交的所有条目。

（1）选举限制

领导人需要保证自己存储全部已经提交的日志条目。这样才可以使日志条目只有一个流向：从领导人流向群众，领导人永远不会覆盖已经存在的日志条目。

每个候选人（Candidate ）发起投票时，都会带上最后一个日志条目的信息。所有节点收到投票信息时，会对该日志条目进行比较，如果发现自己的更新，则拒绝投票给该候选人。

判断日志新旧的方式：如果两个日志的任期号（term）不同，那么任期号大的更新；如果任期号相同，那么索引（index）大的更新。

（2）提交之前任期内的日志条目

只有领导人当前任期里的日志条目可以通过计算副本数目来提交；一旦当前任期的日志条目以这种方式被提交，那么由于日志匹配特性，之前的日志条目也都会被间接的提交。