Raft 协议

Raft 协议

Raft 能为在计算机集群之间部署有限状态机提供一种通用方法，并确保集群内任意节点在某种状态转换上保持一致。

• 集群内的节点都对选举出的领袖采取信任，因此Raft 不是一种拜占庭容错算法

Raft通过选举领袖的方式做共识算法（达成共识）

服务器身份：

• 领袖（leader）
• 追随者（follower）
• 候选人（candidate）

基本规则：

• 正常情况下只有一个领袖，其他都是追随者。
• 由领袖负责所有外部的请求，如果非领袖机器收到，请求会被导向到领袖
• 心跳超时机制，领袖会在固定周期发送消息（心跳），让追随者知道集群的领袖还在运作，并刷新各自的选举超时
• 选举超时机制（timeout），每个追随者都有一个随机的不同的超时设置，当超过一定时间没有接收到心跳，集群就会进入选举状态

Raft将问题拆分成数个子问题分开解决，让人容易了解：

• 领袖选举（Leader Election）
• 记录复写（Log Replication）
• 安全性（Safety）

领袖选举

在开始算法或领袖死机、断线的时候，就需要选举出新的领袖

过程：

• 首先，集群进入新的任期并开始选举，如果成功则新领袖开始运行工作，反之则视为任期终止，开始新的任期和下一场选举。
• 由候选人发起，当领袖心跳超时时，追随者会把自己的任期编号加一、宣告竞选、投自己一票并向其他服务器拉票。每个服务器在每个任期只会投一票，固定投给最早拉票的服务器。
• 如果候选人收到其他候选人的拉票，并且拉票的任期编号不小于自己的编号，就会自认落选，成为追随者，并认定来拉票的候选人为领袖。如果有候选人收到过半选票即当选新领袖。如超时则任期自动结束，开始新任期和下一场选举。
• Raft 每个服务器的超时期限是随机的，以此降低服务器同时竞选的机率，也降低因两个竞选人得票都不过半而选举失败的机率

状态转移图如下所示：

记录复写

记录复写是领袖的责任

• 整个集群有个复写的状态机，可执行外来的指令。领袖接收指令，将其写到自己记录中的新指令部分，然后转发给追随者。如果有追随者没反应，领袖会不断重发指令，直到每个追随者都成功写入记录为止。
• 当领袖收到过半追随者确认写入后，就会把指令视为committed。当追随者发现指令变为committed，就会在其状态机上运行该指令。
• 当领袖死机时，领袖的某些新指令可能还没复写到集群集体，造成集群记录不一致的状态。新领袖会担起重返一致的责任，让每个追随者的记录和它一致。
  • 做法：和每个追随者比对记录，找出两者一致的最后一笔指令，删除追随者之后的指令，把自己之后的指令拷贝给追随者。整个机制完成后，每个服务器记录就回到一致。

日志/记录内容如下所示：

安全性

Raft 保证以下的安全性：

• 选举安全性：每个任期最多只选出一个领袖
• 领袖附加性：领袖只把新指令追加到记录尾端，不会改写或删除已有指令
• 记录符合性：如某个指令在两个记录中的任期和指令序号一样，则保证序号较小的指令也完全一样
• 领袖完整性：如某个指令在某个任期中存储成功，则保证存在于该领袖任期之后的记录中
• 状态机安全性：如某个服务器在其状态机上运行了某指令，其他服务器保证不会在同个状态上运行不同的指令

更多规则和限制

追随者死机

当某追随者死机时，所有给它的转发指令和拉票消息都会因无回应而失败，此时发送端会持续重传。当此追随者重新加入集群，就会收到信息并重新回应。如果转发的指令已经写入，不会重复写入。

超时期限和可用性

由于Raft 引导选举基于超时机制，使得超时期限的设置至关重要。若遵守算法的时限需求：

广播时间 << 超时期限 << 平均故障间隔

就能达到稳定性。三个时限指标定义如下：

• 广播时间，单一服务器发送消息给集群中每台服务器并得到回应的平均时间，由测量得到
• 超时期限，发动选举的超时期限，由部署Raft集群的人设置
• 平均故障间隔，服务器发生故障之间的平均时间，由测量或估计得到

广播时间典型是0.5ms 到20ms，平均故障间隔通常是用周或月计算得来，所以可将超时期限设在10ms到500ms

更多资料

Raft 演示动画

日志压缩

对Raft 的“修正补充”