一文讲清 Raft 核心(Raft 学习系列)

Raft 可能大家对其还有点陌生,但我相信大家都知道 Paxos。但 Paxos 很被理解,反正我现在也不懂。两位研究者也提到,他们也花了很长的时间来理解 Paxos,他们也觉得很难理解,于是研究出了 Raft 算法。

Raft 是工程上使用较为广泛的强一致性、去中心化、高可用的分布式协议。接下来,我就带大家轻松了解 Raft 核心世界。

Leader 选举过程

当启动集群 A、B、C 三个节点时,三个节点都处于 Follower 状态中,在心跳超时时间内没有收到 Leader 节点的信息,某一个节点优先转入 Candidate 状态,并发起一个投票请求,这里假设是 A 节点,A 在发起投票请求之前会先投一票给自己,如果 B 和 C 在收到请求的时候,还处于 election time out ,会直接投给 A ,A 就成为了 Leader 节点,并通知其他节点自己当选,并维护心跳。

一文讲清 Raft 核心(Raft 学习系列)_第1张图片

以上是比较理想情况下的选举过程,我们先提炼一下关键信息:

  • 触发选举条件:心跳超时时间内没有收到 Leader 节点的心跳
  • 当选 Leader 条件:获得最多票数的节点当选

Raft 集群各个节点之间是通过 RPC 通讯传递消息的,每个节点都包含一个RPC 服务端与客户端,初始时启动 RPC 服务端、状态设置为 Follower、启动选举定时器,每个 Raft 节点的选举定时器超时时间都在 100-500 毫秒之间且并不一致。

处于 Candidate 状态的节点会发起一个投票请求,请求内容:候选人任期(term)、候选人ID(candidateId)、日志项索引(lastLogIndex)、日志项任期(lastLogTerm)。响应内容:当前任期(term)、投票结果(voteGranted)。每个任期内,每个 Raft 节点都只能投票一次。

假设 A(Term=1) 发起投票请求时,B(Term=1) 也发起了投票请求(此时B还没有收到A的请求),如果 A 先请求到 C 并及时响应,那么 A(Term=1)。如果出现票数一样的情况,超过选举定时器超时时间,节点进行下一轮的投票请求(Term 加 1)。

如何保证选举票数存在相同的情况(脑裂)?
选举定时器超时时间不同节点不一致
Raft 集群节点数设为奇数

心跳超时时间与选举超时时间怎么定?
当 Follower 节点收到 Leader 节点心跳信息时,会重置选举超时时间,因而,心跳时间应该小于选举时间。

A 能获得 C 的票的前提?

  • 一个节点得到 majority 的投票才能成为 leader,而节点 A 给节点 C 投票的其中一个前提是,C 的日志不能比 A 的日志旧。(下文讲述)
  • C 未发起投票请求,且最先收到 A 的投票请求

Log Replication

当 Leader 被选举出来之后,由 Leader 处理来自客户端的请求,Leader 会对并发处理进行排序,并将这些请求的排序和信息通过心跳的方式传递到 Follower 节点。

完整流程:

  • leader append log entry
  • leader issue AppendEntries RPC in parallel
  • leader wait for majority response
  • leader apply entry to state machine
  • leader reply to client
  • leader notify follower apply log

Log entry
在 Raft 中,Leader 将客户端请求(Command)封装到一个个 Log Entry,并将 Log Entry 按与 Leader 中存储的先后顺序同步到 Follower 节点。

一文讲清 Raft 核心(Raft 学习系列)_第2张图片

从上图中可以看出,Logs 顺序排列的 Log Entry 组成 ,每个 Log Entry 除了包含 Command,还包含产生该 Log Entry 时的 Leader Term。从上图可以看到,5 个节点的日志并不完全一致,Raft 算法为了保证高可用,并不是强一致性,而是最终一致性,Leader 会不断尝试给 Follower 发 Log Entries,直到所有节点的 Log Entries 都相同。

在上面的流程中,Leader 只需要 Log Entry 被复制到大多数节点即可向客户端返回,一旦向客户端返回成功消息,那么系统就必须保证 Log Entry(其实是 Log 所包含的 Command )在任何异常的情况下都不会发生回滚,即:当前 Log Entry 处于 Commited 状态了。

一文讲清 Raft 核心(Raft 学习系列)_第3张图片

正常情况下,一切都是没有问题的,但存在网络问题、Leader 选举等情况从而存在 Follower 与 Leader 之间的数据不一致性。在 Raft 中,一切根据 Leader 数据进行覆盖,因为 Leader 一定包含最新的 Committed Log,这里注意是 Committed Log,也就是说已经被绝大多节点所复制了确认的,不能回滚的日志数据。

其过程是 A 节点收到 Leader 的请求后,对比 Leader 节点记录的上一个日志记录的 index 和 term,发现自己的日志中不存在这个命令,于是拒绝这个请求。此时,Leader 节点知道发生了不一致,于是递减 nextIndex,并重新给A节点发送日志复制请求,直到找到日志一致的地方为止。然后把 Follower 节点的日志覆盖为 Leader 节点的日志内容。

为什么 Leader 具有最新的 committed log?
Raft 在选举的过程中,就存在一个校验项,当选 Leader 的节点 commited 日志数据不能旧于其他节点。

一文讲清 Raft 核心(Raft 学习系列)_第4张图片

在场景 c 中,当前 Leader 为 S1,最新的 log entry 是 4,此时 raft 算法会将最新的 4 的数据同步到各个节点上,顺带对缺失 2 数据信息进行补充,这里要注意是顺带哦,而不是先同步 2,在同步 4。如果 2 数据绝大多数节点都存在了,就可以处于 commited 状态,响应客户端请求,不再允许回滚。

如果 Leader 节点获取大多数的节点的同意,但不同意的节点上存在 log 数据是 Leader 节点所没有的数据呢?
Leader 节点的数据会覆盖该节点的数据。

如果 leader 收不到majority节点的消息呢?
Leader 可以自己 step down,自行转换到 follower 状态。

总结:

Leader 选举:
一个节点得到 majority 的投票才能成为 leader,而节点 A 给节点 B 投票的其中一个前提是,B 的日志不能比 A 的日志旧。
触发选举条件:心跳超时时间内没有收到 Leader 节点的心跳。
当选 Leader 条件:获得最多票数的节点当选。
心跳时间应该小于选举时间。

Log Replication 约束:
一个 Log 被复制到大多数节点,就是 Committed,保证不会回滚。
Leader 一定包含最新的 Committed Log因此 Leader 只会追加日志,不会删除覆盖日志。
不同节点,某个位置上日志相同,那么这个位置之前的所有日志一定是相同的。
Log 数据只允许追加,不允许删除和修改。

参考:

关注我的公众号,能获得第一手的分享内容哦!

一文讲清 Raft 核心(Raft 学习系列)_第5张图片

你可能感兴趣的:(tidb,raft)