Raft 算法

1、Raft 算法

另一种共识算法，目的是比 Paxos 更易理解

整个 Raft 算法分解为三部分：

1. Leader 选举

① 只有一个 Server 能作为 Leader

② 一旦此 Server 崩溃，选举新 Leader

2. 执行操作，以日志复制为例（Log replication）

① 由 Leader 执行自己的日志记录

② 将日志复制到其它 Server，会覆盖掉不一致的部分

③ 多数派记录日志成功，Leader 才能执行命令，向客户端返回结果

3. 确保安全

① 保证日志记录的一致性

② 拥有最新日志的 Server 才能成为 Leader

2、Leader 选举

1. Leader会不断向选民发送 AppendEntries 请求，证明自己活着
2. 选民收到 LeaderAppendEntries 请求后会重置自己的 timeout 时间

   

3. 选民收不到 AppendEntries 请求超时后，转换角色为候选者，并将任期加1，发送 RequestVote 请求，推选自己

   

4. 选民收到第一个 RequestVote，会向该候选者投一票，这样即使有多个候选者，必定会选出一个 Leader，选票过半即当选，如果落选会变回选民

   

5. 每一任期最多有一个 Leader，但也可能没有（选票都不过半的情况，需要再进行一轮投票，timeout 在 T~2T 间随机）

6. 任期由各个 server 自己维护即可，无需全局维护，在超时后加1，在接收到任意消息时更新为更新的任期，遇到更旧的任期，视为错误

3、执行操作（以日志复制为例）

1. 客户端发送命令至 Leader

2. Leader 将命令写入日志（S1虚框），并向所有选民发送 AppendEntries 请求

   

3. 多数派通过后，执行命令（即提交，S1虚框变实），此时就可以向客户端返回结果

   

4. 在后续的 AppendEntries 请求中通知选民，选民执行命令（即提交，S2,S3,S4,S5虚框变实）

   

5. 如果选民挂了，则 Leader 会不断尝试，待到选民重启，会将其缺失的日志陆续补齐

4、确保安全

Leader 日志的完整性

1. Leader 被认为拥有最完整的日志

2. 一旦 Leader 完成了某条命令提交，那么未来的 Leader 也必须存有该条命令提交信息

3. 投票时，会将候选者最新的 随 RequestVote 请求发送，如果候选者的日志还没选民的新，则投否决票

   

• 图中 S2 如果超时，发起选举请求，其它服务器只会对它投否决票，因为它的 Index 比其它人都旧

• 图中 S5 如果超时，发起选举请求，其它服务器也不会选它，因为他的 Term 太旧

选民日志的一致性

1. 以 Leader 为准，对选民的日志进行补充或覆盖

2. AppendEntries 请求发送时会携带最新的 以及上一个的

3. 如果选民发现上一个的 能够对应上则成功，否则失败，继续携带更早的信息进行比对

   

• 图中 Leader 发送了 <3,4,Command> 和 <2,3> 给 follower，follower 发现 <2,3> 能够与当前最新日志对应，这时直接执行 <3,4,Command> 即可

  

• 图中 Leader 发送了 <3,4,Command> 和 <2,3> 给 follower，follower 发现 <2,3> 不能与当前最新日志对应，会央求 Leader 发送更早日志

  

• Leader 这次发送了 <3,4,Command> ， <2,3,Command> ，<1,2> 给 follower，follower 发现 <1,2> 能够与当前最新日志对应，这时补全 <3,4,Command> ， <2,3,Command> 即可

参考资料

• https://www.youtube.com/watch?v=vYp4LYbnnW8 Raft 作者讲解 Raft

• Raft Consensus Algorithm Raft 资源

• Raft Scope Raft 可视化