聊一聊Raft算法的选举以及日志复制 - 原创|技术

Raft 算法是一种用于实现分布式系统中一致性问题的算法，它旨在简化一致性算法的设计，使其更加容易理解和实现。Raft 算法通过选举一个领导者（Leader）来集中处理客户端请求，并通过日志复制机制来确保所有节点的数据一致性。

Raft 算法的基本概念

节点状态：Raft 中的节点可以处于三种状态之一：领导者（Leader）、跟随者（Follower）或候选人（Candidate）。
领导者（Leader）：处理客户端请求，负责日志条目的复制。
跟随者（Follower）：被动地响应来自领导者或候选人的请求。
候选人（Candidate）：尝试成为领导者，发起选举。
任期（Term）：Raft 使用任期来组织时间，每个任期从一次选举开始。任期是连续的整数，每个任期可能有一个领导者，也可能没有。
日志条目（Log Entry）：每个节点维护一个日志，其中包含客户端请求的命令。每个日志条目包含一个任期号，表示它是在哪个任期内被提出的。
心跳（Heartbeat）：领导者定期向跟随者发送心跳消息，以维持其领导地位。

在 Raft 算法中，每个节点的超时时间并不是一样的。为了减少脑裂（split-brain）情况的发生概率，Raft 实现了随机超时时间的特性。这意味着每个节点等待领导者心跳信息的超时时间间隔是随机的。

随机超时时间的目的
1. 减少脑裂的可能性：
  - 如果所有节点的超时时间都是固定的，那么在领导者失败后，所有节点几乎会在同一时刻超时并尝试成为候选人。
  - 这种情况增加了多个节点同时发起选举的可能性，从而增加了脑裂的风险。
2. 提高选举的成功率：
  - 通过设置随机的超时时间，可以使得不同节点在不同的时间点超时，从而减少了同时成为候选人的可能性。
  - 这样可以提高单次选举选出领导者的几率，减少多次选举的需要。

随机超时时间的实现

1. 超时时间范围：
  - 每个节点在转换为候选人状态前，会等待一个随机的时间段。
  - 这个时间段通常在一个指定的范围内，例如 150 到 300 毫秒之间。
2. 超时时间的选择：
  - 当节点从领导者或跟随者状态转变为候选人状态时，它会选择一个随机的超时时间。
  - 这个随机时间是在一个预定义的范围内选择的，以确保节点不会同时超时。

举例说明

假设一个 Raft 集群中有四个节点（Node 1, Node 2, Node 3, Node 4）。如果领导者宕机，每个节点都会开始计时，等待一个随机的超时时间。例如：

Node 1 的超时时间为 160 毫秒。
Node 2 的超时时间为 250 毫秒。
Node 3 的超时时间为 180 毫秒。
Node 4 的超时时间为 200 毫秒。

在这种情况下，Node 1 最先超时，它会增加自己的任期编号，并开始选举过程。如果 Node 1 成功获得大多数节点的投票，它将成为新的领导者。其他节点在超时后会发现已经有领导者存在，并更新自己的状态。

Raft 算法的核心机制

领导者选举

选举过程：
- 当跟随者在一段时间内没有收到领导者的心跳或投票请求时，它会超时并转变为候选人。
- 候选人会向集群中的其他节点发送投票请求（RequestVote RPC）。
- 接收到投票请求的节点如果还没有投票给其他候选人，并且候选人的日志至少与自己的日志一样新，就会投票给该候选人，并回复投票结果（RequestVoteResponse）。
选举规则：
- 如果候选人获得了大多数节点的投票，它就成为新的领导者。如果没有候选人获得多数票，选举将继续进行，直到选出新的领导者。

详细选举过程

初始化状态：
- 所有节点初始状态为跟随者（Follower）。
- 每个节点维护一个当前任期号 currentTerm 和一个投票给谁的变量 votedFor（默认为 null）。
超时机制：
- 跟随者在接收到领导者的心跳或投票请求时，会重置超时计时器。
- 如果跟随者在超时时间内没有收到任何消息，它会转变为候选人（Candidate）。
候选人状态：
- 候选人将自己的任期号 currentTerm 加一，并将自己视为候选人。
- 候选人向所有其他节点发送投票请求（RequestVote 消息）。
- 候选人记录自己已经投了一票给自己，然后等待其他节点的投票回复。
投票请求：
- 候选人发送的 RequestVote 消息包含：
  - 当前任期号 term
  - 候选人的日志信息（最后一条日志的索引和任期号）
- 其他节点收到投票请求后，会根据以下条件决定是否投票：
  - 如果请求中的任期号大于或等于自己的任期号，并且候选人的日志至少与自己的日志一样新，节点会投票给该候选人，并回复 true。
  - 否则，节点回复 false。
投票结果：
- 候选人记录收到的投票数。
- 如果候选人收到了大多数节点的投票（即超过半数），它会转变为领导者（Leader）。
- 如果没有收到大多数投票，候选人会继续等待其他投票结果或重新开始选举过程。
选举超时：
- 如果候选人在一定时间内没有收到足够的投票，它会重新开始选举过程。

日志复制

日志条目的复制：
- 领导者接收到客户端请求后，会在自己的日志中添加新的条目，并向所有跟随者发送 AppendEntries 请求（AppendEntries RPC）。
- 跟随者会检查收到的日志条目是否与其现有的日志匹配，如果不匹配，则拒绝该请求。
- 如果跟随者接受日志条目，它会持久化该条目，并回复给领导者。
日志条目的提交：
- 一个日志条目只有在被大多数节点持久化后才被视为已提交。
- 领导者会跟踪已提交的日志条目，并通过 AppendEntries 请求通知跟随者哪些条目已被提交。

日志条目的复制过程

领导者处理客户端请求：
- 领导者接收到客户端请求后，在自己的日志中添加新的日志条目，并记录该条目的任期号。
- 领导者向所有跟随者发送 AppendEntries 消息，将新的日志条目广播出去。
AppendEntries 消息：
- 领导者发送的 AppendEntries 消息包含：
- 当前任期号 term
- 领导者的日志信息（前缀日志条目的索引和任期号）
- 新的日志条目列表
- 下一个日志条目的索引 nextIndex
- 匹配日志条目的索引 matchIndex
跟随者处理 AppendEntries 消息：
- 跟随者收到 AppendEntries 消息后，会根据以下条件处理：
  - 如果请求中的任期号小于自己的任期号，跟随者回复 false 并忽略该消息。
  - 如果请求中的任期号大于或等于自己的任期号，跟随者更新自己的任期号并转换为跟随者状态。
- 跟随者检查日志条目是否匹配：
  - 如果前缀日志条目匹配，跟随者接受新的日志条目并持久化。
  - 如果前缀日志条目不匹配，跟随者回复 false 并提供最近匹配的日志条目的索引。
日志条目的持久化：
- 跟随者将新的日志条目持久化到本地日志中。
- 跟随者回复 AppendEntriesResponse 消息，确认日志条目已被持久化。
日志条目的提交：
- 领导者记录已复制的日志条目，并计算已提交的日志条目。
- 如果一个日志条目被大多数节点持久化，领导者将其标记为已提交，并通过 AppendEntries 消息通知跟随者。
- 跟随者收到已提交的日志条目后，也将其标记为已提交。

安全性

日志匹配：
- 如果两个日志条目有相同的索引和任期号，则它们包含相同的命令。
- 如果一个日志条目的索引大于另一个日志条目的索引，并且它们的前一条日志条目匹配，则这两个日志条目也匹配。
日志冲突解决：
- 如果跟随者的日志与领导者的日志不匹配，领导者会删除跟随者日志中不匹配的部分，并追加新的日志条目。

详细示例

假设我们有一个 Raft 集群，包含四个节点：A、B、C、D。

1. 选举过程：

初始状态：所有节点都是跟随者。

A 超时后转变为候选人，发送投票请求给 B、C、D。

B、C、D 收到请求后，检查日志并投票给 A。

A 收到大多数投票后成为领导者。

2. 日志复制过程：

领导者 A 接收到客户端请求，添加日志条目到自己的日志中。

A 向 B、C、D 发送 AppendEntries 消息，包含新的日志条目。

B、C、D 收到消息后，检查日志并接受新的日志条目。

B、C、D 回复确认消息给 A。

A 记录已复制的日志条目，并标记为已提交。

A 通过 AppendEntries 消息通知 B、C、D 已提交的日志条目。

B、C、D 标记已提交的日志条目。

Raft 算法的优势

易于理解：Raft 算法通过将问题分解为三个子问题（领导者选举、日志复制和安全性），使得算法更加易于理解和实现。
简化状态：Raft 通过限制节点的状态变化，使得状态转移更加简单。
高性能：通过选举一个领导者来集中处理请求，Raft 可以在大多数情况下提供高性能。
可扩展性：Raft 支持集群成员变更，允许集群在运行时添加或移除节点。

Raft 算法通过选举一个领导者来集中处理客户端请求，并通过日志复制机制确保所有节点的数据一致性。它通过简化状态转移和问题分解来提高算法的可理解性，同时保证了系统的安全性和可用性。

如何能够保证leader的任期是最新的？

在 Raft 算法中，确保领导者的任期是最新的是一项关键任务，因为这关系到整个系统的正确性和一致性。领导者任期的最新性是通过选举过程和日志条目的持久化来保证的。以下是保证领导者任期最新的几个关键机制：

选举过程
在 Raft 中，选举过程确保了具有最新任期的节点成为领导者。以下是选举过程中的一些关键步骤：
1. 超时机制：
  - 节点作为跟随者时，如果在随机超时时间内没有收到领导者的心跳或投票请求，它会转变为候选人，并开始一个新的任期。
  - 这种随机超时机制减少了多个节点同时成为候选人的可能性，从而降低了同时进行多个选举的可能性。
2. 投票请求：
  - 候选人发送投票请求（RequestVote RPC）给集群中的其他节点。
  - 投票请求包含候选人的任期号和日志信息（最后一条日志的索引和任期号）。
3. 投票逻辑：
  - 节点（跟随者或候选人）收到投票请求后，会检查请求中的任期号是否大于自己的任期号。
  - 如果请求中的任期号大于或等于自己的任期号，并且候选人的日志至少与自己的日志一样新，节点会投票给该候选人，并回复 true。
  - 如果请求中的任期号小于自己的任期号，节点会回复 false 并附带自己的任期号。
4. 多数投票：
  - 如果候选人收到大多数节点的投票，它会成为领导者，并开始新的任期。
  - 成为领导者后，它会立即开始发送心跳（AppendEntries RPC）来维护其领导地位。
心跳机制
一旦一个节点成为领导者，它会定期发送心跳消息（AppendEntries RPC）给所有跟随者。这些心跳消息不仅包含了日志条目（如果有新的日志条目的话），更重要的是，它们包含了领导者的任期号。跟随者收到心跳消息后，会更新自己的任期号，并确认领导者是最新的。
任期号的递增
每当一个新的任期开始时，任期号都会递增。这意味着每个任期都有一个唯一的任期号。如果一个节点成为了领导者，它会使用当前的任期号，并在心跳消息中传播这个任期号。跟随者收到心跳消息后，会更新自己的任期号，并确认领导者是最新的。
日志的一致性
领导者在发送新的日志条目时，会确保日志的一致性。如果跟随者的日志与领导者的日志不一致，领导者会调整 nextIndex 并重新发送日志条目，直到跟随者的日志与领导者的一致。这样可以确保所有节点的日志都是一致的，并且最新的日志条目是由当前任期的领导者提交的。
任期号的比较
在 Raft 中，节点会比较收到的消息中的任期号与自己的任期号。如果收到的消息中的任期号更高，节点会放弃当前的角色（无论是领导者还是候选人），转而成为跟随者，并更新自己的任期号。这一机制确保了具有最高任期号的节点能够成为领导者。

如何处理脑裂

在 Raft 算法中，如果发生集群脑裂（split-brain），即集群分割成两个或更多个独立通信的子集，可能会导致不同的子集各自选举出一个领导者，从而导致任期号的一致性问题。处理这种情况的关键在于如何识别脑裂的发生以及如何恢复一致性。

如何识别脑裂

脑裂通常发生在网络分区的情况下，即部分节点之间的通信被中断。在这种情况下，节点无法接收到其他节点的心跳或投票请求，从而可能导致多个节点同时成为候选人，并分别被各自的子集选举为领导者。

如何处理脑裂

任期号的比较：
- 在 Raft 中，每个节点都会维护一个当前的任期号。当一个节点收到一个来自其他节点的消息时，它首先会检查该消息中的任期号。
- 如果收到的消息中的任期号大于自己的任期号，节点会放弃当前的角色（无论是领导者还是候选人），转而成为跟随者，并更新自己的任期号。
- 这样做可以确保具有更高任期号的节点成为领导者。
心跳机制：
- 领导者会定期向跟随者发送心跳消息（AppendEntries RPC），这些心跳消息包含了领导者的任期号。
- 如果跟随者收到一个任期号更高的心跳消息，它会更新自己的任期号，并确认新的领导者是最新的。
- 心跳机制有助于快速识别并恢复一致性。
选举超时机制：
- 在脑裂情况下，一个子集中的节点可能无法接收到心跳消息，从而超时并尝试重新进行选举。
- 如果两个子集各自选举出了一个领导者，那么当网络恢复正常后，其中一个任期号较低的领导者会发现自己不再是领导者，因为它会接收到任期号更高的领导者的心跳消息。
日志条目的一致性：
- 如果脑裂期间，两个领导者各自提交了一些日志条目，那么在恢复一致性时，任期号较高的领导者会负责日志条目的复制。
- 如果任期号较低的领导者提交的日志条目与任期号较高的领导者冲突，任期号较高的领导者会通过日志复制机制来解决这些冲突，确保日志的一致性。

示例说明

1、假设一个 Raft 集群分为两个子集，每个子集选举了一个领导者（Leader A 和 Leader B），任期分别为 Term 10 和 Term 11。

网络恢复后：

Leader A（Term 10）和 Leader B（Term 11）开始互相发送心跳消息。
当 Leader A 收到 Leader B 的心跳消息时，它会发现 Leader B 的任期号更高（Term 11 > Term 10），因此 Leader A 会放弃领导者身份，成为跟随者，并更新自己的任期号为 Term 11。
Leader B 继续作为领导者，并通过心跳消息维持其领导地位。

2、假设在脑裂期间，集群被分为两部分，一部分选出了 Leader A，任期为 Term 10；另一部分选出了 Leader B，任期为 Term 10。Leader A 在 Term 10 提交了日志条目 X，而 Leader B 在 Term 10 提交了日志条目 Y。

网络恢复后的处理：
- 当网络恢复后，Leader A 和 Leader B 会互相发送心跳消息。
- 由于它们的任期号相同，需要通过其他机制来确定谁是真正的领导者。
选举超时机制：
- 在 Raft 中，如果两个领导者任期相同，它们会继续发送心跳消息以维持各自的领导地位。
- 如果其中一个领导者收到了另一个节点的更高任期号的心跳消息，它会放弃领导者身份，成为跟随者，并更新自己的任期号。
日志条目的冲突解决：
- 如果网络恢复后，两个领导者任期相同，并且它们的日志条目不一致，需要通过日志条目的冲突解决机制来处理。
- 通常情况下，Raft 会通过日志条目的持久化和多数节点的确认来决定哪个日志条目有效。

具体步骤

心跳消息：
- Leader A 和 Leader B 互相发送心跳消息。
- 由于任期号相同，它们需要进一步确认谁是真正的领导者。
日志条目的持久化：
- Leader A 和 Leader B 都会检查自己的日志条目是否已经被大多数节点持久化。
- 如果某个日志条目已经被大多数节点持久化，那么这个日志条目就是有效的。
多数节点确认：
- 如果 Leader A 的日志条目 X 被大多数节点持久化，那么 X 应该保留。
- 如果 Leader B 的日志条目 Y 被大多数节点持久化，那么 Y 应该保留。
冲突解决：
- 如果 Leader A 和 Leader B 的日志条目都没有被大多数节点持久化，需要通过进一步的选举来决定谁是真正的领导者。
- 可能会有新的选举过程，其中一个节点会成为新的领导者，并负责日志条目的复制。

示例说明

假设在脑裂期间，集群被分为两部分，一部分选出了 Leader A，任期为 Term 10；另一部分选出了 Leader B，任期为 Term 10。Leader A 在 Term 10 提交了日志条目 X，而 Leader B 在 Term 10 提交了日志条目 Y。

网络恢复后：
- Leader A 和 Leader B 互相发送心跳消息。
- 由于任期号相同，它们需要进一步确认谁是真正的领导者。
日志条目的持久化：
- Leader A 检查自己的日志条目 X 是否已经被大多数节点持久化。
- Leader B 检查自己的日志条目 Y 是否已经被大多数节点持久化。
多数节点确认：
- 假设 Leader A 的日志条目 X 已经被大多数节点持久化，那么 X 应该保留。
- 假设 Leader B 的日志条目 Y 没有被大多数节点持久化，那么 Y 应该被删除。
冲突解决：
- 如果 Leader A 的日志条目 X 被大多数节点持久化，那么 Leader A 成为真正的领导者。
- Leader B 会放弃领导者身份，成为跟随者，并更新自己的日志条目。

除非注明，否则均为哦豁原创文章，转载必须以链接形式标明本文链接

本文链接：https://www.ohuuo.com/archives/original/216