一、概要

Raft算法属于Multi-Paxos算法，它是在Multi-Paxos思想的基础上，做了一些简化和限制，比如增加了日志必须是连续的，只支持领导者、跟随者和候选人三种状态，在理解和算法实现上都相对容易许多。

二、领导者选举

2.1 成员身份

Raft算法支持领导者（Leader）、跟随者（Follower）和候选人（Candidate）3种状态：

• 跟随者：接收和处理来自领导者的消息，当等待领导者心跳信息超时的时候，就主动站出来，推荐自己当候选人
• 候选人：候选人将向其他节点发送请求投票（RequestVote）RPC消息，通知其他节点来投票，如果赢得了大多数选票，就晋升当领导者
• 领导者：负责处理写请求、管理日志复制和不断地发送心跳信息，通知其他节点“我是领导者，我还活着，你们现在不要发起新的选举，找个新领导者来替代我”。

Raft算法是强领导者模型，集群中只能有一个领导者。

2.2 选举领导者的过程

在初始状态下，集群中所有的节点都是跟随者状态。

 Raft算法实现了随机超时时间的特性，每个节点等待领导者心跳信息的超时时间间隔是随机的。上图中，集群中没有领导者，而节点A的等待超时时间最小，它会最先因为没有等到领导者的心跳信息，发生超时。这时，节点A增加自己的任期编号，并推举自己为候选人，先给自己投上一张选票，然后向其他节点发送请求投票RPC消息，请它们选举自己为领导者。

如果其他节点接收到候选人A的请求投票RPC消息，在编号为1的这届任期内，也还没有进行过投票，那么它将把选票投给节点A，并增加自己的任期编号。

 如果候选人在选举超时时间内赢得了大多数的选票，那么它就会成为本届任期内新的领导者。

 节点A当选领导者后，它将周期性地发送心跳消息，通知其他服务器我是领导者，阻止跟随者发起新的选举。

2.3 节点间如何通讯？

在Raft算法中，服务器节点间的沟通联络采用的是远程过程调用（RPC），在领导者选举中，需要用到这两类的RPC：

• 请求投票（RequestVote）RPC：是由候选人在选举期间发起，通知各节点进行投票
• 日志复制（AppendEntries）RPC：是由领导者发起，用来复制日志和提供心跳消息

 2.4 什么是任期？

Raft算法中每个任期由单调递增的数字（任期编号）标识，任期编号是随着选举的举行而变化的。

1. 跟随者在等待领导者心跳信息超时后，推举自己为候选人时，会增加自己的任期编号，比如节点A的任期编号为0，那么在推举自己为候选人时，会将自己的任期编号增加为1
2. 如果一个服务器节点，发现自己的任期编号比其他节点小，那么它会更新自己的任期编号到较大的编号值，比如节点B的任期编号是0，当收到来自节点A的请求投票RPC消息时，因为消息中包含了节点A的任期编号，且编号为1，那么节点B将把自己的任期编号更新为1
3. 如果一个候选人或者领导者，发现自己的任期编号比其他节点小，那么它会立即恢复成跟随者状态。比如分区错误恢复后，任期编号为3的领导者节点B，收到来自新领导者的包含任期编号为4的心跳消息，那么节点B将立即恢复成跟随者状态
4. 如果一个节点接收到一个包含较小的任期编号值的请求，那么它会直接拒绝这个请求。比如节点C的任期编号为4，收到包含任期编号为3的请求投票RPC消息，那么它将拒绝这个消息

2.5 选举有哪些规则？

1. 领导者周期性地向所有跟随者发送心跳消息（即不包含日志项的日志复制RPC消息），通知大家我是领导者，组织跟随者发起新的选举
2. 如果在指定时间内，跟随者没有接收到来自领导者的消息，那么它就认为当前没有领导者，推举自己为候选人，发起领导者选举
3. 在一次选举中，赢得大多数选票的候选人，将晋升为领导者
4. 在一个任期内，领导者一直都会是领导者，直到它自身出现问题（比如宕机），或者因为网络延迟，其他节点发起一轮新的选举
5. 在一次选举中，每一个服务器节点最多会对一个任期编号投出一张选票，并且按照先来先服务的原则进行投票。比如节点C的任期编号为3，先收到了一个包含任期编号为4的投票请求（来自节点A），然后又收到了一个包含任期编号为4的投票请求（来自节点B）。那么节点C将会把唯一一张选票投给节点A，当再收到节点B的投票请求RPC消息时，对于编号为4的任期，已没有选票可投了。

6. 日志完整性高的跟随者（也就是最后一条日志项对应的任期编号值更大，索引号更大）拒绝投票给日志完整性低的候选人。比如节点B的任期编号为3，节点C的任期编号为4，节点B的最后一条日志项对应的任期编号为3，而节点C为2，那么当节点C请求节点B投票给自己时，节点B将拒绝投票。

 选举是跟随者发起的，推举自己为候选人；大多数选票是指集群成员半数以上的选票；大多数选票规则的目标，是为了保证在一个给定的任期内最多只有一个领导者。

2.6 随机超时时间是什么？

Raft算法使用随机选举超时时间的方法，把超时时间都分散开来，在大多数情况下只有一个服务器节点先发起选举，而不是同时发起选举，这样就能减少因选票瓜分导致选举失败的情况。

在Raft算法中，随机超时时间有2种含义：

1. 跟随者等待领导者心跳信息超时的时间间隔是随机的
2. 如果候选人在一个随机时间间隔内，没有赢得过半票数，那么选举就无效了，然后候选人发起新一轮的选举，也就是说，等待选举超时的时间间隔是随机的

2.7 补充

1）Raft算法的强领导者模型选举限制和局限如下：

1. 读写请求和数据转发压力落在领导者节点，相当于单机，性能和吞吐量也会受到限制
2. 大规模跟随者的集群，领导者需要承担大量元数据维护和心跳通知的成本
3. 领导者单点问题，故障后直到新领导者选举出来期间集群不可用
4. 随着候选人规模增长，收集半数以上投票的成本更大

2）强领导者模型会限制集群的写性能，有什么办法能突破Raft集群的写性能瓶颈呢？

三、日志复制

3.1 如何理解日志

副本数据是以日志的形式存在的，日志是由日志项组成，日志项是一种数据格式，它主要包含用户指定的数据，也就是指令（Command），还包含一些附加信息，比如索引值（Log index）、任期编号（Term）。

• 指令：一条由客户端请求指定的、状态机需要执行的指令，可以理解成客户端指定的数据
• 索引值：日志项对应的整数索引值，用来标识日志项的，是一个连续的、单调递增的证书号码
• 任期编号：创建这条日志项的领导者的任期编号

 3.2  如何复制日志？

首先，领导者通过日志复制（AppendEntries）RPC消息，将日志项复制到集群其他节点上

接着，如果领导者接收到大多数的复制成功响应后，它将日志项应用到它的状态机，并返回成功给客户端。如果领导者没有接收到大多数的复制成功响应，那么就返回错误给客户端

领导者将日志项应用到它的状态机，怎么没通知跟随者应用日志项呢？

因为领导者的日志复制RPC消息或心跳消息，包含了当前最大的、将会被提交的日志项索引值。所以通过日志复制RPC消息或心跳消息，跟随者就可以知道领导者的日志提交位置信息.

1. 接收到客户端请求后，领导者基于客户端请求中的指令，创建一个新日志项，并附加到本地日志中
2. 领导者通过日志复制RPC，将新的日志复制到其他的服务器
3. 当领导者将日志项成功复制到大多数的服务器上的时候，领导者会将这条日志项应用到它的状态机中
4. 领导者将执行的结果返回给客户端
5. 当跟随者接收到心跳消息，或者新的日志复制RPC消息后，如果跟随者发现领导者已经提交了某条日志项，而它还没应用，那么跟随者就将这条日志项应用到本地的状态机上。

3.3 如何实现日志的一致？

 在Raft算法中，领导者通过强制跟随者直接复制自己的日志项，处理不一致日志。也就是说，Raft是通过以领导者的日志为准，来实现各节点日志的一致性的。

1. 首先，领导者通过日志复制RPC的一致性检查，找到跟随者节点上与自己相同日志项的最大索引值。也就是说，这个索引值之前的日志，领导者和跟随者是一致的，之后的日志是不一致的。
2. 然后，领导者强制跟随者更新覆盖不一致的日志项，实现日志的一致。

引入2个新变量：

• PrevLogEntry：表示当前要复制的日志项，前面一条日志项的索引值。比如下图中，如果领导者将索引值为8的日志项发送给跟随者，那么此时PrevLogEntry值为7。
• PrevLogTerm：表示当前要复制的日志项，前面一条日志项的任期编号，比如在图中，如果领导者将索引值为8的日志项发送给跟随者，那么此时PrevLogTerm值为4。

1. 领导者通过日志复制RPC消息，发送当前最新日志项到跟随者，这个消息的PrevLogEntry值为7、PrevLogTerm值为4
2. 如果跟随者在它的日志中，找不到PrevLogEntry值为7、PrevLogTerm值为4的日志项，也就是说它的日志和领导者的不一致了，那么跟随者就会拒绝接收新的日志项，并返回失败消息给领导者
3. 这时，领导者会递减要复制的日志项的索引值，并发送新的日志项到跟随者，这个消息的PrevLogEntry值为6、PrevLogTerm值为3
4. 如果跟随者在它的日志中，找到了PrevLogEntry值为6、PrevLogTerm值为3的日志项，那么日志复制RPC返回成功，这样一来，领导者就知道在PrevLogEntry值为6、PrevLogTerm值为3的位置，跟随者的日志项与自己相同
5. 领导者通过日志复制RPC复制并更新覆盖该索引值之后的日志项（也就是不一致的日志项），最终实现了集群各节点日志的一致

3.4 补充

1）领导者接收到大多数的“复制成功”响应后，就会将日志应用到它自己的状态机，然后返回“成功”响应客户端。如果此时有个节点不在“大多数”中，也就是说它接收日志项失败，那么在这种情况下，Raft会如何处理实现日志的一致呢？

处理日志项一致通过RPC一致性检查，找到跟随者中与自己相同日志项的最大索引，然后把后面的日志项同步过去，让跟随者复制更新

2）Raft在处理日志不一致时会给跟随者发送RPC一致性检查，找到和自己相同日志项的最大值，这里是对每个跟随者而言的还是所有的跟随者而言的？

日志复制信息对每个跟随者都要单独维护的

————————————————
版权声明：本文为CSDN博主「邋遢的流浪剑客」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_40378034/article/details/117404484

原文地址：http://www.cnblogs.com/cuijy1/p/16851812.html