Raft 算法

default

前提

CAP 理论中,只能保证三者中两者的存在

  • C(Consistence)一致性
  • A(Availability)可用性
  • P(Partition tolerance)分区容错性

概要

  • leader:领导者,负责提议的发起、提交被大多数认可的判决

  • candidate:候选人,竞选领导者

  • follower:响应提议、提交和选举

Leader 广播心跳的机制

Leader 通过广播心跳包的方式证明自己的健康并同步日志,心跳包含Term(任期)和Log(日志)。

  • 接收方为Leader,则从接收到的心跳中判断任期大小
    • 如果发送方的任期更大,则接收方Leader自动退位
    • 如果发送方任期比自己小,则忽视
  • 接收方为Follower,判断任期大小
    • 如果发送方任期比自己大,则更新自己的任期,重置心跳定时器,判断并更新Leader发来的更新日志
    • 如果发送方任期比自己小,则忽视
  • 接受发为 Candidate,判断任期大小
    • 如果发送方任期比自己大,自己退位成Follower
    • 如果发送方任期比自己小,则忽视

假如 Follower的任期比该Leader更新,则返回拒绝并带上当前任期号,该 Leader 通过返回包判断已有任期比自己新,则转变成 Follower。

Leader 的选举

Follower 在定时器后仍未接收到旧Leader的心跳,则发现旧 Leader 宕机,同时将自己提升为 Candidate,发起拉票选举。

其他 Follower 判断任期及日志索引为最新,则投赞同票,否则投拒绝。

其他的 Leader/Candidate 判断该 Candidate 的任期,如果比自己新,则放弃自己身份转为 Follower,否则拒绝投票。该 Candidate 收到赞成票数量大于半数,则升级为 Leader。

如果发现其他Candidate拒绝且返回的任期比自己新,则退回成Follower,更新任期;如果选举超时则重新发起选举。

Follower 的脏数据

前任 Leader 发出请求后,已推送到部分 follower,但是还没有投票通过到提交,此时该 Leader 宕机,follower会重新选举新 Leader,新Leader中如果没有该请求日志,则在有该请求日志的follower中存在脏数据。会在新Leader广播心跳时,follower的脏数据会进行清除,保证本地日志与Leader一一致。


参考

【1】解析分布式共识算法之Raft算法

Licensed under CC BY-NC-SA 4.0
Gear(夕照)的博客。记录开发、生活,以及一些不足为道的思考……