一文搞懂Raft算法：核心概念与工作流程

在构建高可用、容错性强的分布式系统时，我们经常会遇到一个核心问题：如何让系统中的多个节点就某个状态或行为达成一致？例如，在一个分布式键值存储系统中，当一个客户端请求写入数据时，如何确保这个写入操作被所有节点都接受并按照相同的顺序执行？又或者，当主节点发生故障时，如何确保系统能够自动选举出一个新的主节点并继续提供服务？

这些问题都指向了分布式系统中的一个基本挑战——一致性（Consensus）。一致性算法是解决这个问题的关键工具。其中，Paxos算法是最早被提出的经典算法，它在理论上是完备的，但以其高度的复杂性而闻名，难以理解和实现。为了解决Paxos的复杂性问题，斯坦福大学的Diego Ongaro和John Ousterhout于2014年提出了Raft算法。Raft的设计目标是将一致性算法分解为几个相对独立的、易于理解和实现的子问题，从而提高算法的可理解性（Understandability），同时保证与Paxos相同的容错能力和性能。

Raft算法因其清晰的设计思路和相对较低的实现难度，在工业界得到了广泛应用，成为了许多分布式系统的基石，如etcd、Consul、TiKV等。本文将深入浅出地解析Raft算法的核心概念和完整工作流程，帮助您彻底理解Raft。

1. 为什么需要一致性算法？

在分布式系统中，节点可能随时发生故障（崩溃停止、网络分区等）。如果没有一致性算法，不同节点可能会对系统的状态产生不同的“认知”，导致数据不一致、服务不可用甚至更严重的问题。例如：

分布式数据库的主备复制： 如果主节点写入了一批数据，但在同步给备节点之前宕机了，备节点上位后可能缺少部分数据，导致数据丢失或不一致。
分布式锁服务： 如果多个客户端同时请求同一个锁，没有一致性机制可能导致多个客户端都认为自己获取了锁，引发冲突。
配置管理服务： 系统配置需要全局唯一且一致，否则不同服务实例可能读取到不同的配置，行为异常。

一致性算法的目标就是在存在节点故障、网络延迟或分区的情况下，确保所有节点对一个共享状态或操作顺序达成共识。Raft算法就是一种能够实现强一致性（Linearizability）的分布式一致性算法。

2. Raft的设计哲学：可理解性优先

Raft算法的设计者认为，尽管 Paxos 在理论上是优雅的，但其复杂性是阻碍它广泛应用的主要原因。Raft 的设计理念是“可理解性优先”，通过以下方式来实现：

问题分解： 将一致性问题分解为几个相对独立的子问题：
- 领导者选举（Leader Election）： 如何在宕机的节点中选举出一个新的领导者。
- 日志复制（Log Replication）： 如何让领导者接收客户端请求，并将其以日志条目的形式复制到其他节点，确保所有节点有相同的日志序列。
- 安全性（Safety）： 如何确保系统不会返回错误的结果，例如，保证在任何情况下，已提交（committed）的日志条目都不会被回滚，以及领导者选举和日志复制过程中的各种不变量。
简化的状态空间： Raft 限制了节点的行为，每个节点在任何时候都只能处于三种状态中的一种，并且状态之间的转换是明确定义的。
强制领导者模型： Raft 总是存在一个领导者，所有的客户端请求都必须通过领导者处理，由领导者负责协调日志复制。这大大简化了协调逻辑。
确定性的角色： 每个节点在任何时候都扮演明确的角色（领导者、追随者、候选人）。

3. Raft的核心概念

理解Raft，需要先掌握几个关键概念：

3.1 节点状态 (States)

Raft 集群中的每个节点在任何时刻都处于以下三种状态之一：

追随者 (Follower)： 集群中的大多数节点都处于此状态。追随者完全被动，只响应来自领导者和候选人的请求。如果追随者在一段时间内没有收到领导者的心跳包（AppendEntries RPC），它会认为领导者可能已经宕机，然后转变为候选人状态，发起新的选举。
候选人 (Candidate)： 当追随者超时没有收到领导者心跳后，它会转变为候选人状态，开始进行领导者选举。候选人会向其他节点发送请求投票（RequestVote RPC），试图赢得选举成为新的领导者。
领导者 (Leader)： 集群中在任意一个时刻最多只有一个领导者。领导者负责处理所有客户端请求，并将更新操作以日志条目的形式复制给所有追随者。领导者还会定期发送心跳包给追随者，以维持其领导地位并阻止新的选举发生。

(图片来源: Raft Consensus Algorithm Extended)

状态转换规则：

追随者 → 候选人：当追随者在选举超时时间内没有收到领导者的心跳或有效信息时。
候选人 → 领导者：当候选人赢得了大多数节点的投票时。
候选人 → 追随者：
- 收到了当前任期号更大的领导者的心跳。
- 在选举过程中，收到了其他节点发来的任期号更大（或相同但已是领导者）的投票请求或心跳，并且发现已经有新的领导者产生了。
领导者 → 追随者：当领导者发现自己的任期号落后于其他节点（例如，收到了任期号更大的请求），这意味着有新的领导者产生了，它会立即退位成为追随者。
所有状态 → 追随者：如果节点发现任何 RPC 请求或响应中的任期号大于自身当前的任期号，它会立即更新自己的任期号并转变为追随者状态。这是Raft处理过期信息和节点复活的基础机制。

3.2 任期 (Terms)

Raft将时间划分为一个个离散的、连续的任期（Term）。任期通过单调递增的整数来标识。每个任期都是从一次选举开始的：

一个节点从追随者转变为候选人时，它会增加当前的任期号，然后开始新的任期。
如果一个候选人赢得选举，它将成为该任期的领导者。
领导者在整个任期内有效。在某些情况下，一个任期内可能没有领导者（例如，选举失败，发生裂脑）。

任期是Raft中重要的逻辑时钟。节点之间通过交换任期号来发现过期的信息。如果一个节点发现自己当前的任期号小于通信对方的任期号，它会立即更新自己的任期号为对方的任期号，并转变为追随者状态。如果一个节点收到了任期号小于自己当前任期号的请求，它会拒绝这个请求。

3.3 RPC (Remote Procedure Calls)

Raft 算法通过两种主要的 RPC 来实现节点间的通信：

请求投票 (RequestVote RPC)： 由候选人在选举期间发起，用于向其他节点请求投票。
- 参数：
  - term：候选人的任期号。
  - candidateId：候选人自身的ID。
  - lastLogIndex：候选人最后一条日志条目的索引。
  - lastLogTerm：候选人最后一条日志条目的任期号。
- 接收者逻辑：
  - 如果接收者（可以是Follower或Candidate）的任期小于 term，则更新自己的任期为 term 并转变为Follower，然后投票给该候选人（如果满足投票条件）。
  - 如果接收者的任期大于或等于 term，则拒绝投票。
  - 如果接收者的任期等于 term，但已经投过票给其他候选人，则拒绝投票。
  - 如果接收者的日志不如候选人新（通过比较 lastLogTerm 和 lastLogIndex 判断，后面会详细解释），则拒绝投票。
  - 满足以上条件，且尚未在当前任期投票给其他候选人，则投票给该候选人，并重置选举计时器。
- 响应：
  - term：接收者当前的任期号（用于让候选人更新自己的任期）。
  - voteGranted：布尔值，表示是否投给了该候选人。
附加日志条目 (AppendEntries RPC)： 由领导者发起，用于日志复制和发送心跳。
- 参数：
  - term：领导者的任期号。
  - leaderId：领导者自身的ID。
  - prevLogIndex：新日志条目紧前面的日志条目的索引（用于一致性检查）。
  - prevLogTerm：新日志条目紧前面的日志条目的任期号（用于一致性检查）。
  - entries[]：需要复制的日志条目数组（可能为空，作为心跳）。
  - leaderCommit：领导者已经提交的最高日志条目索引。
- 接收者逻辑：
  - 如果接收者的任期小于 term，则拒绝请求。
  - 如果接收者的任期大于 term，则更新自己的任期为 term 并转变为Follower，然后拒绝请求。
  - 如果任期号一致，进行一致性检查：如果接收者的日志在 prevLogIndex 位置的任期号与 prevLogTerm 不匹配，则拒绝请求，并告知领导者需要回退 nextIndex。
  - 一致性检查通过后，接收者将领导者发来的新日志条目附加到自己的日志中。如果新日志条目与接收者已有的日志发生冲突（相同索引，不同任期号），则删除接收者从该索引及其之后的所有日志，然后附加新的日志条目。
  - 更新接收者的 commitIndex 为 leaderCommit 和自身最后一个日志条目索引中较小的一个。
  - 响应成功。
- 响应：
  - term：接收者当前的任期号（用于让领导者更新自己的任期）。
  - success：布尔值，表示是否成功附加了日志条目。
  - conflictTerm, conflictIndex: （可选）当一致性检查失败时，Follower可以返回导致冲突的日志条目的任期和索引，帮助Leader快速回退 nextIndex。

3.4 日志 (Log)

Raft中的日志是核心数据结构，它是一个有序的、只能追加（append-only）的记录序列。每个日志条目（Log Entry）包含：

命令 (Command)： 一个状态机需要执行的命令（例如，“设置键值对 x=10”）。
任期号 (Term)： 创建该日志条目时的领导者的任期号。
索引 (Index)： 日志条目在日志序列中的位置（从1开始递增）。

(图片来源: Raft Consensus Algorithm Extended)

日志在Raft中起着至关重要的作用：

状态机的输入： 所有的客户端请求都作为日志条目被记录，然后按照相同的顺序应用到状态机（State Machine）上，从而保证所有节点的状态一致。
复制状态： 领导者通过将新的日志条目复制到大多数追随者来维护集群的一致性。
实现安全性： 日志条目的任期号和索引用于在领导者选举和日志复制过程中执行一致性检查，确保关键的安全性属性。

日志一致性原则：

如果不同服务器上的两条日志条目拥有相同的索引和任期号，那么它们存储了相同的命令。
如果不同服务器上的两条日志条目拥有相同的索引和任期号，那么它们在日志中的所有前驱日志条目也都完全相同。

第一个原则由领导者强制执行：领导者在一个任期内最多在给定的日志索引创建一个日志条目，并且日志条目永远不会被修改。第二个原则通过 AppendEntries RPC 的一致性检查来实现：当领导者发送 AppendEntries RPC 时，它会包含新日志条目前一条日志条目的索引和任期号。如果追随者找不到匹配的条目，它会拒绝请求。领导者会据此回退并重试 AppendEntries RPC，直到找到一致点，然后删除追随者冲突的日志条目并追加领导者的日志。

3.5 提交 (Commit)

当领导者成功地将一个日志条目复制到大多数节点（包括领导者自身）时，该日志条目被认为是已提交（Committed）的。

领导者会维护一个 commitIndex，表示当前集群中已知已提交的最高日志条目的索引。领导者通过 AppendEntries RPC 将这个 commitIndex 告知追随者。追随者在收到领导者的 commitIndex 后，会更新自己的 commitIndex，并将所有索引小于等于 commitIndex 且尚未应用的日志条目按顺序应用到它们各自的状态机上。

重要的提交规则：

领导者只能提交当前任期内的日志条目。这是为了防止在领导者切换过程中出现问题。具体来说，一个日志条目在被复制到大多数节点后，只有当领导者又成功复制了至少一个当前任期的日志条目到大多数节点时，才能确保该日志条目被提交（即使该日志条目本身来自之前的任期）。这个规则保证了领导者完备性。
一旦日志条目被提交，它及其之前的所有日志条目就永远不会被回滚，并且会最终被所有可用的状态机执行。

3.6 状态机 (State Machine)

每个 Raft 节点都有一个状态机。状态机是确定性的：给定一个初始状态和一系列有序的命令输入，它总是会产生相同的最终状态。

Raft 的日志条目包含了状态机需要执行的命令。当一个日志条目被提交后，节点会按照日志索引顺序将该日志条目包含的命令应用（Apply）到状态机上，从而改变系统的状态。

领导者维护一个 lastApplied 索引，表示最后一个被应用到状态机的日志条目索引。追随者也会维护自己的 lastApplied 索引。节点会不断地将日志条目从 lastApplied + 1 到 commitIndex 依次应用到状态机。

3.7 定时器 (Timers)

Raft 使用定时器来驱动领导者选举过程：

选举超时 (Election Timeout)： 每个追随者都有一个选举超时定时器。如果在选举超时时间内没有收到来自领导者的有效通信（心跳或 AppendEntries），追随者会认为领导者已失效，转变为候选人并发起选举。选举超时时间通常设置为一个随机值（例如 150-300 毫秒），这是为了分散节点发起选举的时间，减少分裂投票（Split Vote）的可能性。
心跳间隔 (Heartbeat Interval)： 领导者周期性地（通常远小于选举超时时间，例如 50 毫秒）发送空的 AppendEntries RPC 作为心跳，以维持其领导地位并防止追随者发起新的选举。

4. Raft的工作流程详解

了解了核心概念后，我们来详细看看Raft是如何工作的。

4.1 初始化

集群启动时，所有节点都处于追随者状态。它们不知道谁是领导者，也没有日志。每个追随者都启动一个选举超时定时器。

4.2 领导者选举 (Leader Election)

领导者选举由追随者的选举超时触发。

追随者超时： 如果一个追随者在选举超时时间内没有收到来自当前领导者的心跳或 AppendEntries RPC，它会认为领导者可能已宕机。
转变为候选人： 追随者将自己的状态转变为候选人。
开始新的任期： 候选人会增加当前的任期号。
投票给自己： 候选人首先投票给自己。
发送 RequestVote RPC： 候选人向集群中的所有其他节点发送 RequestVote RPC。
- RequestVote 请求中包含候选人的当前任期号、ID，以及它自己的最后一条日志条目的索引 (lastLogIndex) 和任期号 (lastLogTerm)。
追随者接收 RequestVote RPC：
- 如果追随者收到的 RequestVote 请求中的任期号小于自己的当前任期号，它会拒绝投票。
- 如果任期号大于或等于自己的当前任期号，追随者首先会更新自己的任期号为请求中的任期号，并转变为追随者状态（如果它之前是候选人或领导者）。然后，它会根据两个条件决定是否投票给该候选人：
  - 尚未在当前任期内投票给其他人： 每个追随者在一个给定的任期内最多只能投一票（给第一个满足条件的候选人）。
  - 候选人的日志至少和自己的日志一样新： 这是选举安全性中最关键的一点。为了保证领导者完备性（即已提交的日志条目最终会出现在所有未来的领导者的日志中），Raft 要求一个候选人必须拥有集群中大多数节点都拥有的、最新的日志条目才能当选领导者。比较日志新旧的规则是：
    - 比较最后一条日志条目的任期号：任期号大的更“新”。
    - 如果任期号相同，则比较日志条目的索引：索引大的更“新”。
    - 只有当候选人的 lastLogTerm 大于或等于追随者的 lastLogTerm，并且在任期号相同时，候选人的 lastLogIndex 大于或等于追随者的 lastLogIndex 时，追随者才会投票给该候选人。
- 如果追随者投票给候选人，它会重置其选举超时定时器。
候选人接收 RequestVote 响应：
- 如果候选人收到了来自大多数（N/2 + 1，N为节点总数）节点的投票（包括自己的投票），它就赢得了选举。
- 赢得选举： 候选人转变为领导者状态。它会立即向所有追随者发送 AppendEntries RPC（心跳，可能包含空的 entries[]），以建立并维持其领导地位，并阻止新的选举。领导者会为每个追随者维护 nextIndex（将要发送给该追随者的下一条日志条目的索引）和 matchIndex（已知该追随者已复制的最高日志条目索引）。
- 发现任期更高的节点： 如果候选人收到了来自其他节点（无论是 RequestVote 响应还是 AppendEntries 请求）的任期号大于自身任期号，这意味着已经有其他节点进入了更高的任期甚至已经选出了新的领导者。候选人会立即更新自己的任期号，并转变为追随者状态。
- 选举超时，未赢得大多数投票： 如果选举超时，但候选人没有收到大多数节点的投票，它会开始新的任期，并再次转变为候选人（或根据实现的不同，等待一段时间再开始新的选举），重复选举过程。分裂投票（多个候选人同时发起选举，票数分散导致谁也无法获得多数）可能导致这种情况发生，随机的选举超时时间有助于减少分裂投票的概率。

4.3 日志复制 (Log Replication)

一旦选出领导者，它就开始处理客户端请求。

客户端请求： 所有客户端请求都必须发送到领导者。如果客户端连接到追随者，追随者会将请求重定向到领导者。
领导者追加日志： 领导者收到客户端请求后，会创建一个新的日志条目，包含命令和领导者的当前任期号，并将其追加到自己的日志中（此时日志条目处于未提交状态）。
领导者发送 AppendEntries RPC： 领导者并行地向所有追随者发送 AppendEntries RPC，其中包含新的日志条目。RPC 参数包括 prevLogIndex 和 prevLogTerm，用于追随者进行一致性检查。
- 领导者会维护每个追随者的 nextIndex，表示下一个要发送给该追随者的日志条目索引。初始时，nextIndex 设置为领导者最后一条日志条目索引 + 1。每次成功发送 AppendEntries 后，领导者会更新对应追随者的 nextIndex。
- 领导者也会维护每个追随者的 matchIndex，表示已知该追随者已复制的最高日志条目索引。初始时为 0。
追随者接收 AppendEntries RPC：
- 追随者首先进行任期检查（如果领导者的任期小于自己的任期，拒绝；如果领导者的任期大于自己的任期，更新任期并转为追随者）。
- 然后进行一致性检查：检查自己的日志中是否存在索引为 prevLogIndex 且任期号为 prevLogTerm 的条目。
  - 检查失败： 如果不存在或任期号不匹配，追随者拒绝 AppendEntries 请求，并返回 success=false 以及可能的冲突信息（如冲突条目的任期和索引）。
  - 检查成功： 如果一致性检查通过，追随者会删除自身日志中从 prevLogIndex + 1 开始的所有日志条目（因为这些条目与领导者的日志冲突），然后将 AppendEntries RPC 中的新日志条目附加到自己的日志中。
- 追随者更新自己的 commitIndex 为 leaderCommit 和自身最后一个日志条目索引中较小的一个。
- 追随者返回 success=true。
领导者处理 AppendEntries 响应：
- 成功响应 (success=true)： 领导者更新对应追随者的 nextIndex 和 matchIndex。
  - nextIndex 更新为发送的最后一个日志条目索引 + 1。
  - matchIndex 更新为发送的最后一个日志条目索引。
- 失败响应 (success=false)： 如果是由于一致性检查失败（日志不匹配），领导者会递减对应追随者的 nextIndex，然后重试 AppendEntries RPC。这个过程会一直重复，直到找到领导者和追随者日志中的一致点，然后追随者就可以开始接收并复制领导者的日志。如果是因为任期问题（领导者任期小于追随者），领导者会更新自己的任期并退位成为追随者。
日志提交： 当领导者发现一个日志条目已经被大多数追随者成功复制（通过比较 matchIndex）并且该日志条目是当前任期创建的，领导者就认为该日志条目可以被提交了。领导者会更新自己的 commitIndex 到这个日志条目的索引。
- 重要说明： 虽然领导者可以将来自前任期的日志条目复制到大多数节点，但它不能直接依赖这个事实来提交这些前任期的条目。只有当领导者成功复制并提交了至少一个当前任期的日志条目到大多数节点时，它才能确定之前任期的所有日志条目（直到当前任期提交的条目为止）也都被提交了。这是为了处理少数派节点拥有已提交日志，但多数派没有，且旧领导者宕机后新领导者未能选上拥有该已提交日志的节点的边缘情况。通过强制提交当前任期条目，确保了领导者完备性。
应用到状态机： 领导者和追随者一旦得知某个日志条目已提交（通过更新的 commitIndex），就会将该日志条目包含的命令应用到各自的状态机上，并更新 lastApplied 索引。客户端的请求在对应的日志条目被应用到领导者的状态机后，就可以被认为已经成功处理，领导者会向客户端返回响应。

4.4 心跳机制

领导者通过定期发送空的 AppendEntries RPC 来作为心跳。这有两个作用：

维持领导者地位： 追随者收到心跳后会重置选举超时定时器，从而不会发起新的选举。
通知追随者 LeaderCommit： 心跳中包含领导者的 commitIndex，追随者可以根据这个信息更新自己的 commitIndex，从而应用已提交的日志条目。

如果追随者长时间没有收到心跳，就会触发选举超时，开始新的选举过程。

4.5 处理节点故障

Raft能够容忍少于半数节点的崩溃故障、网络延迟和分区。

追随者故障： 追随者故障不会影响系统的可用性。领导者会不断重试 AppendEntries RPC，直到故障追随者恢复。恢复后，追随者会接收并同步领导者的日志。
候选人故障： 候选人故障只会导致该轮选举失败，其他节点会继续进行选举。
领导者故障： 这是最常见且重要的故障场景。当前领导者宕机后，追随者会因选举超时而发起新的选举，选出新的领导者，然后系统继续运行。新领导者会通过 AppendEntries 机制让所有节点日志一致。

4.6 安全性属性 (Safety Properties)

Raft 通过其设计规则保证了以下关键安全性属性：

选举安全性 (Election Safety)： 在一个给定的任期内，最多只能选出一个领导者。这是通过“每个节点在每个任期内最多投一票”和“赢得选举需要大多数投票”这两个规则保证的。
领导者完备性 (Leader Completeness)： 如果一个日志条目在某个任期内被提交，那么所有更高任期的领导者都必须包含该日志条目。这是通过选举规则（候选人的日志必须至少和大多数节点一样新才能当选领导者）和日志复制规则（领导者通过 AppendEntries 强制追随者与自己日志一致）共同保证的。任何已提交的条目一定存在于大多数节点的日志中，而新当选的领导者必须拥有大多数节点的最新日志，因此它必然拥有所有已提交的日志。
日志匹配属性 (Log Matching Property)： 如果不同服务器上的两个日志条目拥有相同的索引和任期号，那么它们在日志中的所有前驱日志条目也都完全相同。这是通过 AppendEntries RPC 的一致性检查强制实现的。
状态机安全性 (State Machine Safety)： 如果一个服务器已经将某个索引位置的日志条目应用到其状态机中，那么其他任何服务器都不会在同一个索引位置应用不同的日志条目。这是日志匹配属性和提交规则共同保证的。一旦日志条目被提交并应用，它就不会改变。

4.7 集群成员变更 (Cluster Membership Changes)

在实际应用中，集群的节点数量可能会动态变化（增加或删除节点）。在分布式一致性算法中，动态成员变更是一个复杂的问题，因为它需要在变更过程中同时维持一致性。

Raft采用了一种称为联合一致性 (Joint Consensus) 的两阶段方法来处理成员变更，避免在变更过程中出现分裂投票或导致系统不可用的情况。简单来说，变更过程分为两个阶段：

过渡配置 (C_{old,new})： 集群首先进入一个过渡状态，同时包含旧的节点集合（C_{old}）和新的节点集合（C_{new}）。在这个阶段：
- 日志复制到 C_{old} 和 C_{new} 中的大多数节点。
- 提交需要 C_{old} 的大多数和 C_{new} 的大多数节点都确认。
- 领导者选举需要 C_{old} 的大多数和 C_{new} 的大多数节点都投票。
新配置 (C_{new})： 一旦过渡配置的日志条目被提交，领导者就向集群复制并提交一个新的日志条目，其中包含最终的新配置 C_{new}。一旦这个 C_{new} 配置被提交，集群就完全切换到新的配置，并根据 C_{new} 来进行日志复制和领导者选举。

这个过程确保了在任何时候，大多数的概念都是明确且安全的，避免了在不同配置下的节点对多数形成不同的理解。

4.8 日志压缩 (Log Compaction / Snapshotting)

Raft 日志会随着时间的推移不断增长，这会消耗大量磁盘空间，并且节点启动时回放整个日志来恢复状态的开销也会很大。为了解决这个问题，Raft 引入了日志压缩机制，通常通过快照 (Snapshotting) 来实现。

当领导者决定进行快照时，它会：

将当前状态机的状态序列化到一个文件中。
记录生成快照时状态机所对应的最后一个已应用的日志条目的索引（lastIncludedIndex）和任期号（lastIncludedTerm）。
丢弃该索引之前的所有日志条目和旧的快照。

领导者会周期性地向追随者发送快照（通过 InstallSnapshot RPC）。追随者接收快照后：

如果快照中的 lastIncludedIndex 小于等于追随者已应用到状态机的索引，则拒绝快照（说明追随者的状态更新）。
如果快照中的 lastIncludedIndex 大于追随者已应用到状态机的索引，追随者丢弃其整个日志（或至少是 lastIncludedIndex 之前的部分）和旧的快照。
加载快照到状态机中，更新其状态到快照的状态。
创建一个新的、空的日志，其中包含一个伪造的日志条目，索引为 lastIncludedIndex，任期号为 lastIncludedTerm。
更新 commitIndex 和 lastApplied 为 lastIncludedIndex。

快照机制使得节点无需从头回放所有历史日志即可快速恢复到最新状态，显著提高了系统的效率和可扩展性。

5. Raft与Paxos的对比

再次回到 Raft 的初衷，与 Paxos 相比，Raft 的优势主要体现在可理解性上：

角色分明： Raft 将一致性算法分解为领导者选举、日志复制和安全性等独立问题，并为每个节点定义了清晰的状态和角色，职责单一。Paxos 的角色（Proposer, Acceptor, Learner）在不同的阶段可能由不同的节点扮演，且过程更为抽象。
强制领导者： Raft 始终维持一个领导者，所有请求都经过领导者。Paxos 允许多个 Proposer 同时存在，它们之间可能发生冲突，需要额外的机制来解决。
简化的日志结构： Raft 的日志是一个简单的、连续的序列，通过 AppendEntries RPC 的一致性检查来保证日志的复制和修复。Paxos 的日志概念相对分散，没有 Raft 这样统一且强化的日志复制过程。
更直观的流程： Raft 的选举过程和日志复制过程相对直观，易于循序渐进地理解。Paxos 的多数派协议和多阶段提交过程相对复杂。

尽管 Raft 在可理解性上更优，但在容错能力和性能上与 Paxos 是相当的，都能在异步网络环境下容忍少于半数的节点故障。Raft 通常被认为是更适合实际系统实现的一致性算法。

6. Raft的应用

由于其易于理解和实现的特性，Raft 已被广泛应用于各种需要分布式一致性的系统中：

分布式协调服务： etcd（Kubernetes 的核心组件）、Consul（服务发现和配置管理）。
分布式存储系统： TiKV（PingCAP 的分布式键值存储）、CockroachDB（分布式关系型数据库）。
分布式消息队列： Kafka 的一些版本或相关的实现中使用了类似 Raft 的机制。
其他分布式系统： 需要选举领导者、协调分布式事务、管理分布式状态的各种系统。

7. 总结

Raft算法是一种用于管理复制日志的分布式一致性算法，其核心设计目标是可理解性。它将一致性问题分解为领导者选举、日志复制和安全性三个子问题。通过定义清晰的节点状态（追随者、候选人、领导者）、时间概念（任期），以及两种主要的RPC（RequestVote和AppendEntries），Raft构建了一个相对直观且易于实现的共识机制。

Raft的工作流程主要包括：节点启动时成为追随者；追随者超时后转变为候选人并发起选举；候选人通过RequestVote RPC争取大多数投票成为领导者；领导者通过AppendEntries RPC复制客户端请求作为日志条目到大多数追随者；一旦日志条目被复制到大多数节点并满足提交条件，它们就被提交并应用到状态机；领导者通过定期发送心跳维护其地位。

通过强制领导者模型、严格的日志一致性检查以及基于大多数的决策机制，Raft保证了分布式系统在存在故障时的安全性和活性。虽然存在集群成员变更和日志快照等更复杂的细节，但Raft的核心机制清晰且易于掌握，这使其成为构建可靠分布式系统的热门选择。

希望通过本文的详细阐述，您能对Raft算法的核心概念和工作流程有一个全面而深入的理解。掌握Raft，是深入理解和构建现代分布式系统的坚实一步。