thor雷神项目Raft算法精讲复制状态机与领导者选举完整图解【免费下载链接】thor项目地址: https://gitcode.com/gh_mirrors/thor3/thorRaft算法是目前最流行的分布式一致性算法之一而复制状态机与领导者选举正是它的两大核心机制。在 thor雷神项目中MIT 6.824 课程的 lec06/tolerance_raft_1.srt 和 lec07/tolerance_raft_2.en.srt 两讲完整字幕用大量黑板图解带你吃透 Raft 的每一个细节。本文面向零基础新手用最直观的方式图解 Raft 算法中的复制状态机、领导者选举与日志复制帮你一次搞懂分布式系统中最难啃的共识问题。为什么需要 Raft 算法先理解分布式系统的共识难题容错系统里的复制套路在分布式系统中单台机器随时可能崩溃。为了容错Fault Tolerance我们通常把数据复制到多台机器上。MIT 6.824 课程里提到过两种经典模式系统复制方式局限MapReduce计算复制由单一 Master 控制Master 是单点故障GFSPrimary-Backup主备复制依赖单一 Master 选主你会发现这些方案都有一个老大Master而老大挂了怎么办就是共识算法要解决的问题。Raft 算法的目标就是让一群平等的服务器在没有单一权威的情况下依然能就日志顺序达成一致。复制状态机Raft 算法最核心的思想什么是复制状态机复制状态机Replicated State Machine是 Raft 算法要实现的最终目标让集群中每一台服务器以完全相同的顺序执行完全相同的命令。只要执行顺序一致、命令确定性一致所有服务器的状态就会一模一样。用一张图理解客户端命令流: [cmd1] - [cmd2] - [cmd3] - ... | | | ┌────────────┼─────────┼─────────┼────────────┐ ▼ ▼ ▼ ▼ ▼ 服务器A日志: [1][2][3] 服务器B日志: [1][2][3] 服务器C日志: [1][2][3] │ │ │ │ │ ▼ ▼ ▼ ▼ ▼ 状态机A 状态机B 状态机C (三台状态完全一致)课程中特别强调这个顺序对复制状态机来说非常重要日志本身就是复制状态机的一部分。命令不能乱序执行一旦顺序错乱各服务器的状态就会分叉。为什么顺序如此重要假设一个银行账户初始余额为 0命令是加 100和加 50服务器 A 执行顺序加100 → 加50余额 150服务器 B 执行顺序加50 → 加100余额 150这个例子碰巧结果一样但如果命令是加100和翻倍呢顺序不同结果天差地别。所以 Raft 必须保证所有服务器看到完全相同的命令序列这就是复制状态机的意义。领导者选举Raft 如何选出老大为什么 Raft 需要一个 Leader课程里老师问了这个问题为什么系统需要 leader 答案是Paxos 没有 leader 也能工作但实现极其复杂。Raft 选择了一条更聪明的路——先选出一个领导者Leader由它统一负责日志复制。这样就把复杂的共识问题简化成了领导者说了算大家跟着执行。Raft 的三种角色完整的角色图解Raft 把服务器分成三种状态任何时刻一台服务器只处于其中一种角色中文职责转换条件 Leader领导者接收客户端请求统一分发日志选举中获得多数派选票️ Candidate候选人发起选举拉票跟随者超时未收到心跳 Follower跟随者被动接收日志投票收到心跳或新任期信息三种状态的转换关系┌─────────────────────────────────────────┐ │ │ ▼ │ ┌─────────┐ 选举超时发起投票 ┌────────────┐ │ Follower│ ─────────────────────► │ Candidate │ └─────────┘ └────────────┘ ▲ │ │ │ 获得多数派选票 │ │ 选举超时 │ ┌─────────────────────────────┘ │ │ ▼ │ │ ┌────────┐ 发现更高任期 ▼ └──│ Leader │ ◄──────────────────────┘ └────────┘Term任期号Raft 的时间标尺Raft 用**任期Term**来标记时间它是一个单调递增的逻辑时钟每个任期最多只有一个 Leader有的任期可能没有 Leader选举失败服务器之间通信时总是携带自己当前的任期号如果服务器收到比自己任期号小的 RPC会直接拒绝任期号更大的请求则会让它乖乖让位。课程中强调它只要知道当前的 term 号就行了这一设计让 Raft 变得异常简单可靠。少数服从多数Raft 安全性的基石为什么必须 majorityRaft 的所有决策选举、提交都依赖多数派Majority。为什么多数派如此神奇课程里举了个例子3 台服务器中 2 台同意就能推进5 台中 3 台同意就行。关键在于多数派之间必然有交集服务器A ●──────┐ 服务器B ●──────┼──► 多数派1AB 服务器C ●──────┘ (下一次选举) 多数派2 必然至少包含一台多数派1的成员课程原话这个 majority 保证和上一次 leader 选举中的 majority 有重叠。正是这个交集让新 Leader 必然知道上一任 Leader 使用过的 Term 号从而保证不会丢失已提交的数据。这是 Raft 安全性的根本来源。日志复制Leader 如何让所有服务器保持一致AppendEntries RPC日志复制的核心机制当选出 Leader 后客户端请求会统一发给 Leader。Leader 把命令作为**日志条目Log Entry**追加到自己的日志中然后通过 AppendEntries RPC 并行发送给所有跟随者。日志复制的完整流程客户端 ──► Leader ──► 追加到本地日志 (未提交) │ ├── AppendEntries ──► Follower A ✅ ├── AppendEntries ──► Follower B ✅ └── AppendEntries ──► Follower C ❌ (崩溃) │ ▼ 收到多数派(2/3)确认 Leader 将条目标记为 committed │ ▼ 下一次心跳/AppendEntries 通知 Follower 执行命令, 更新状态机一致性检查如何发现并修复分叉的日志新 Leader 会为每个跟随者维护一个nextIndex下一条要发送的日志位置。发送 AppendEntries 时会携带previousLogIndex和previousLogTerm前一条日志的索引和任期号。跟随者会做一致性检查如果自己前一条日志的索引和任期号不匹配就拒绝该 RPC。Leader 收到拒绝后就把 nextIndex 往前退一格再试直到找到双方日志一致的位置然后覆盖后面的冲突条目。课程中详细演示了三台服务器日志不一致时 Leader 如何逐格回退、最终削平补齐的过程Leader日志: [1][2][3][4][5] ← 基准 FollowerA: [1][2][3][4][5] ✅ 完全一致 FollowerB: [1][2][3][5][7] ✏️ 覆盖冲突条目 → [1][2][3][4][5] FollowerC: [1][2] ✏️ 补发缺失条目 → [1][2][3][4][5]注意Raft 只会覆盖未提交的条目绝不会删除已提交的条目这是通过 majority 交集保证的。领导者选举完整图解一个任期的诞生过程把上面所有知识点串起来看一次完整选举Term 5: Leader A 正常运行, 定期发送心跳 (AppendEntries) 给 B、C │ ▼ A 突然崩溃 B、C 收不到心跳, 等待选举超时 │ ▼ B 先超时 (超时时间是随机的!) B 变成 Candidate, term 变为 6, 给自己投一票 │ ├── RequestVote ──► C (C 还没有投票记录) │ ▼ │ C 检查: B 的日志不比自己的旧 → 投 B 一票 ✅ │ ▼ B 获得 2 票 (自己 C) 多数派(3台中的2台) │ ▼ B 成为 Term 6 的 Leader, 立刻广播心跳确立地位这里有个精妙的细节选举超时时间是随机的。课程中提到如果 B 和 C 同时超时发起选举就可能出现票数分裂平票导致选举失败。随机超时大大降低了这种概率让系统更快稳定下来。新手最容易踩的 5 个坑坑正确姿势以为 Leader 是永久的Leader 随时可能崩溃任期号必须单调递增忽略任期号比较RPC 中任期号小的请求必须拒绝提交只看 Leader 本地日志必须等多数派确认后才能提交忘记一致性检查previousLogIndex/Term 不匹配必须拒绝选举超时设置相同必须随机化否则频繁平票死循环从哪里开始学thor 项目给你最好的中文资源thor雷神项目是一个社区翻译 MIT 6.824 2020 课程的协作项目字幕质量非常高双语对照。Raft 相关资源路径如下Raft 第一讲容错与复制状态机lec06/tolerance_raft_1.srt涵盖复制状态机思想、majority 投票、term 任期Raft 第二讲日志复制与一致性检查lec07/tolerance_raft_2.en.srt详细图解 AppendEntries、日志回退修复前置基础线程与 Raft 入门lec05/threads_and_raft.en.srtRaft 前的铺垫GFS 主备复制lec04/primary_backup_replication.en.srt术语速查表glossary.md包含容错、复制、分片等核心术语对照如果想动手实现可以参考 MIT 6.824 的 Lab 2Raft 实现课程字幕中特别提示 leader election 是 Lab2 需要完成的内容。字幕里老师详细讲解了每一行核心代码的设计意图配合本文的图解相信你能轻松拿下 Raft。小结Raft 算法之所以广受欢迎是因为它把复杂的共识问题拆成了三个可独立理解的子问题领导者选举谁来发号施令、日志复制命令如何分发、安全性保证已提交数据不丢失。复制状态机是目标majority 是保障term 是时间标尺——把这三件事想清楚Raft 就不再是玄学而是一套逻辑严密的工程方案。希望这篇图解能帮你迈过分布式系统学习中最难的一道坎。想系统学习记得从 thor 项目的字幕资源入手双语对照、逐行精读收获会远超预期。【免费下载链接】thor项目地址: https://gitcode.com/gh_mirrors/thor3/thor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
thor雷神项目Raft算法精讲复制状态机与领导者选举完整图解【免费下载链接】thor项目地址: https://gitcode.com/gh_mirrors/thor3/thorRaft算法是目前最流行的分布式一致性算法之一而复制状态机与领导者选举正是它的两大核心机制。在 thor雷神项目中MIT 6.824 课程的 lec06/tolerance_raft_1.srt 和 lec07/tolerance_raft_2.en.srt 两讲完整字幕用大量黑板图解带你吃透 Raft 的每一个细节。本文面向零基础新手用最直观的方式图解 Raft 算法中的复制状态机、领导者选举与日志复制帮你一次搞懂分布式系统中最难啃的共识问题。为什么需要 Raft 算法先理解分布式系统的共识难题容错系统里的复制套路在分布式系统中单台机器随时可能崩溃。为了容错Fault Tolerance我们通常把数据复制到多台机器上。MIT 6.824 课程里提到过两种经典模式系统复制方式局限MapReduce计算复制由单一 Master 控制Master 是单点故障GFSPrimary-Backup主备复制依赖单一 Master 选主你会发现这些方案都有一个老大Master而老大挂了怎么办就是共识算法要解决的问题。Raft 算法的目标就是让一群平等的服务器在没有单一权威的情况下依然能就日志顺序达成一致。复制状态机Raft 算法最核心的思想什么是复制状态机复制状态机Replicated State Machine是 Raft 算法要实现的最终目标让集群中每一台服务器以完全相同的顺序执行完全相同的命令。只要执行顺序一致、命令确定性一致所有服务器的状态就会一模一样。用一张图理解客户端命令流: [cmd1] - [cmd2] - [cmd3] - ... | | | ┌────────────┼─────────┼─────────┼────────────┐ ▼ ▼ ▼ ▼ ▼ 服务器A日志: [1][2][3] 服务器B日志: [1][2][3] 服务器C日志: [1][2][3] │ │ │ │ │ ▼ ▼ ▼ ▼ ▼ 状态机A 状态机B 状态机C (三台状态完全一致)课程中特别强调这个顺序对复制状态机来说非常重要日志本身就是复制状态机的一部分。命令不能乱序执行一旦顺序错乱各服务器的状态就会分叉。为什么顺序如此重要假设一个银行账户初始余额为 0命令是加 100和加 50服务器 A 执行顺序加100 → 加50余额 150服务器 B 执行顺序加50 → 加100余额 150这个例子碰巧结果一样但如果命令是加100和翻倍呢顺序不同结果天差地别。所以 Raft 必须保证所有服务器看到完全相同的命令序列这就是复制状态机的意义。领导者选举Raft 如何选出老大为什么 Raft 需要一个 Leader课程里老师问了这个问题为什么系统需要 leader 答案是Paxos 没有 leader 也能工作但实现极其复杂。Raft 选择了一条更聪明的路——先选出一个领导者Leader由它统一负责日志复制。这样就把复杂的共识问题简化成了领导者说了算大家跟着执行。Raft 的三种角色完整的角色图解Raft 把服务器分成三种状态任何时刻一台服务器只处于其中一种角色中文职责转换条件 Leader领导者接收客户端请求统一分发日志选举中获得多数派选票️ Candidate候选人发起选举拉票跟随者超时未收到心跳 Follower跟随者被动接收日志投票收到心跳或新任期信息三种状态的转换关系┌─────────────────────────────────────────┐ │ │ ▼ │ ┌─────────┐ 选举超时发起投票 ┌────────────┐ │ Follower│ ─────────────────────► │ Candidate │ └─────────┘ └────────────┘ ▲ │ │ │ 获得多数派选票 │ │ 选举超时 │ ┌─────────────────────────────┘ │ │ ▼ │ │ ┌────────┐ 发现更高任期 ▼ └──│ Leader │ ◄──────────────────────┘ └────────┘Term任期号Raft 的时间标尺Raft 用**任期Term**来标记时间它是一个单调递增的逻辑时钟每个任期最多只有一个 Leader有的任期可能没有 Leader选举失败服务器之间通信时总是携带自己当前的任期号如果服务器收到比自己任期号小的 RPC会直接拒绝任期号更大的请求则会让它乖乖让位。课程中强调它只要知道当前的 term 号就行了这一设计让 Raft 变得异常简单可靠。少数服从多数Raft 安全性的基石为什么必须 majorityRaft 的所有决策选举、提交都依赖多数派Majority。为什么多数派如此神奇课程里举了个例子3 台服务器中 2 台同意就能推进5 台中 3 台同意就行。关键在于多数派之间必然有交集服务器A ●──────┐ 服务器B ●──────┼──► 多数派1AB 服务器C ●──────┘ (下一次选举) 多数派2 必然至少包含一台多数派1的成员课程原话这个 majority 保证和上一次 leader 选举中的 majority 有重叠。正是这个交集让新 Leader 必然知道上一任 Leader 使用过的 Term 号从而保证不会丢失已提交的数据。这是 Raft 安全性的根本来源。日志复制Leader 如何让所有服务器保持一致AppendEntries RPC日志复制的核心机制当选出 Leader 后客户端请求会统一发给 Leader。Leader 把命令作为**日志条目Log Entry**追加到自己的日志中然后通过 AppendEntries RPC 并行发送给所有跟随者。日志复制的完整流程客户端 ──► Leader ──► 追加到本地日志 (未提交) │ ├── AppendEntries ──► Follower A ✅ ├── AppendEntries ──► Follower B ✅ └── AppendEntries ──► Follower C ❌ (崩溃) │ ▼ 收到多数派(2/3)确认 Leader 将条目标记为 committed │ ▼ 下一次心跳/AppendEntries 通知 Follower 执行命令, 更新状态机一致性检查如何发现并修复分叉的日志新 Leader 会为每个跟随者维护一个nextIndex下一条要发送的日志位置。发送 AppendEntries 时会携带previousLogIndex和previousLogTerm前一条日志的索引和任期号。跟随者会做一致性检查如果自己前一条日志的索引和任期号不匹配就拒绝该 RPC。Leader 收到拒绝后就把 nextIndex 往前退一格再试直到找到双方日志一致的位置然后覆盖后面的冲突条目。课程中详细演示了三台服务器日志不一致时 Leader 如何逐格回退、最终削平补齐的过程Leader日志: [1][2][3][4][5] ← 基准 FollowerA: [1][2][3][4][5] ✅ 完全一致 FollowerB: [1][2][3][5][7] ✏️ 覆盖冲突条目 → [1][2][3][4][5] FollowerC: [1][2] ✏️ 补发缺失条目 → [1][2][3][4][5]注意Raft 只会覆盖未提交的条目绝不会删除已提交的条目这是通过 majority 交集保证的。领导者选举完整图解一个任期的诞生过程把上面所有知识点串起来看一次完整选举Term 5: Leader A 正常运行, 定期发送心跳 (AppendEntries) 给 B、C │ ▼ A 突然崩溃 B、C 收不到心跳, 等待选举超时 │ ▼ B 先超时 (超时时间是随机的!) B 变成 Candidate, term 变为 6, 给自己投一票 │ ├── RequestVote ──► C (C 还没有投票记录) │ ▼ │ C 检查: B 的日志不比自己的旧 → 投 B 一票 ✅ │ ▼ B 获得 2 票 (自己 C) 多数派(3台中的2台) │ ▼ B 成为 Term 6 的 Leader, 立刻广播心跳确立地位这里有个精妙的细节选举超时时间是随机的。课程中提到如果 B 和 C 同时超时发起选举就可能出现票数分裂平票导致选举失败。随机超时大大降低了这种概率让系统更快稳定下来。新手最容易踩的 5 个坑坑正确姿势以为 Leader 是永久的Leader 随时可能崩溃任期号必须单调递增忽略任期号比较RPC 中任期号小的请求必须拒绝提交只看 Leader 本地日志必须等多数派确认后才能提交忘记一致性检查previousLogIndex/Term 不匹配必须拒绝选举超时设置相同必须随机化否则频繁平票死循环从哪里开始学thor 项目给你最好的中文资源thor雷神项目是一个社区翻译 MIT 6.824 2020 课程的协作项目字幕质量非常高双语对照。Raft 相关资源路径如下Raft 第一讲容错与复制状态机lec06/tolerance_raft_1.srt涵盖复制状态机思想、majority 投票、term 任期Raft 第二讲日志复制与一致性检查lec07/tolerance_raft_2.en.srt详细图解 AppendEntries、日志回退修复前置基础线程与 Raft 入门lec05/threads_and_raft.en.srtRaft 前的铺垫GFS 主备复制lec04/primary_backup_replication.en.srt术语速查表glossary.md包含容错、复制、分片等核心术语对照如果想动手实现可以参考 MIT 6.824 的 Lab 2Raft 实现课程字幕中特别提示 leader election 是 Lab2 需要完成的内容。字幕里老师详细讲解了每一行核心代码的设计意图配合本文的图解相信你能轻松拿下 Raft。小结Raft 算法之所以广受欢迎是因为它把复杂的共识问题拆成了三个可独立理解的子问题领导者选举谁来发号施令、日志复制命令如何分发、安全性保证已提交数据不丢失。复制状态机是目标majority 是保障term 是时间标尺——把这三件事想清楚Raft 就不再是玄学而是一套逻辑严密的工程方案。希望这篇图解能帮你迈过分布式系统学习中最难的一道坎。想系统学习记得从 thor 项目的字幕资源入手双语对照、逐行精读收获会远超预期。【免费下载链接】thor项目地址: https://gitcode.com/gh_mirrors/thor3/thor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
)
