# Raft神课深读：让分布式系统说人话的一堂课 ## 概述 如果你只打算学一个分布式系统算法，那应该是 Raft——不是因为它最快，而是因为它是唯一一个“以让人看懂为设计目标”的共识算法。今天深读的这条视频，来自 MIT 6.824 分布式系统公开课（2020 春季学期）的 Raft 专题讲座，是该系列中被反复推荐、被全球无数工程师当作“共识算法第一课”的经典一讲。这条课讲透了 Raft 的全部骨架：Leader 选举、日志复制、安全性约束，以及它背后那场针对 Paxos 的“可理解性革命”。看完本文，你不仅能复述 Raft 的工作机制，还能理解一个更深的问题：**算法的可读性，本身就是一种工程能力**。 ## 视频基本信息 | 项目 | 内容 | |------|------| | 讲座主题 | Raft：可理解的共识算法（In Search of an Understandable Consensus Algorithm） | | 所属课程 | MIT 6.824 Distributed Systems（Spring 2020）Raft 专题讲（上、下两讲） | | 主讲机构 | MIT 计算机科学与人工智能实验室（PDOS 组），主讲人为课程教师团队 | | 频道 | MIT 6.824 课程官方频道（YouTube） | | 发布时间 | 2020 年春季学期公开课期间陆续上线（据课程主页） | | 热度 | 长期被视为该系列播放量与引用度最高的专题之一；据频道页面 | | 配套材料 | 课程主页公开全部讲义、Go 语言 Lab 代码框架与测试用例 | *注：本文写作时未能重新核验频道页面的实时数据，具体播放量以频道页面为准。课程信息据 MIT 6.824 官方课程主页（pdos.csail.mit.edu/6.824）。* ## 核心主张拆解：这堂课到底讲了什么 ### 要点一：问题的起点——复制状态机 讲座开篇没有直接讲算法，而是先立住了 Raft 要解决的问题：**复制状态机（Replicated State Machine）**。想象一组服务器，如果它们以完全相同的顺序执行完全相同的命令日志，那么无论谁活着，对外表现都像一台永不宕机的机器。这就是 KV 存储、配置中心、元数据服务能够做到“主节点挂了业务不中断”的原理。 问题在于：谁来确定“命令的顺序”？各台机器之间网络会延迟、丢包、乱序，机器本身会宕机、重启。让一群互相不信任时序的机器，对“第 N 条命令是什么”达成一致——这就是共识（Consensus）问题。6.824 的讲师强调了一个课堂事实：这是分布式系统课程中最难的一讲，也是工业界用得最多的一讲。 ### 要点二：Paxos 的统治与失败 算法史上不是没有答案——Leslie Lamport 的 Paxos 从 1998 年正式发表（"The Part-Time Parliament"）到 2001 年用白话重写（"Paxos Made Simple"），几乎垄断了共识领域十几年。Google Chubby、Spanner 都基于 Paxos 变体。 但讲座转述了 Raft 作者团队的判断，这也是整个研究故事的戏剧性所在：**Paxos 正确，但难教、难学、更难实现**。它的描述方式是“先给出一个单决策（single decree）的算法，再拼装成多决策系统”，而这个拼装过程论文从未真正完成；它的正式证明与工程实现之间隔着一道鸿沟，导致每个 Paxos 实现都是从零摸索，且彼此不兼容。Raft 论文原话的潜台词是：**为一个难懂的正确性买单，不值得**。 ### 要点三：Raft 的答案——分解与强 Leader Raft 的方法论极其工程化，讲座把它概括为三招： **第一招，问题分解。** 把共识拆成三个相对独立的子问题：Leader 选举、日志复制、安全性约束。每个子问题可以单独理解、单独测试。 **第二招，减少需要考虑的状态。** 引入强 Leader 模型：所有日志只能从 Leader 流向 Follower，数据单向下发。你不需要在脑中同时推演多节点各自决策的排列组合。 **第三招，化不确定性为确定性。** 用逻辑时钟“任期（term）”给时间切片：每个任期最多一个 Leader，任期内通过心跳维持权威，通信中携带任期号，过期的消息直接拒绝。逻辑时间取代物理时间，是整个算法能被推理的基石。 ### 要点四：Leader 选举——心跳失联就竞选 选举机制本身很朴素：Follower 在随机超时时间内（通常 150–300ms 区间）没收到 Leader 心跳，就自荐为 Candidate，向所有人拉票（RequestVote RPC），拿到**多数派**选票即上位。随机化超时是为了打破平局——两个节点同时发起选举时，随机错开的下次超时让先到者赢，避免无限对峙。 讲座特别点出三个容易忽略的细节：选票是“先到先得且每任期一票”，保证一个任期不会选出两个 Leader；候选人自己的日志若不够新，会被拒绝（这是安全性约束的前哨站）；当选后 Leader 立即广播心跳宣示权威，抑制新一轮选举。 ### 要点五：日志复制——多数派确认才算数 客户端请求到达 Leader 后，Leader 把命令追加到本地日志，并行发给所有 Follower（AppendEntries RPC）。当**过半节点**都存下这条日志，Leader 就将其标记为 committed，应用到状态机，并响应客户端。Follower 的日志由 Leader 负责修补：一致性检查机制会让落后者按 Leader 的日志逐条覆盖。 这里藏着 Raft 最精妙也最反直觉的一条规则，讲座花了很大篇幅铺垫它：**Leader 只能通过复制当前任期的日志，间接提交前任遗留的日志**。直接提交旧任期日志可能造成已提交的数据被覆盖——这个边界情况（论文图 8 的场景）是整个算法安全性的核心，也是 Lab 测试最爱抓的地方。 ### 要点六：安全性约束——三条不变量撑起正确性 Raft 论文列出五条安全性质，讲座重点讲了其中三条： - **选举限制（Election Restriction）**：投票者必须拒绝日志不如自己新的候选人。比较规则是先比最后一条日志的任期号，再比索引。 - **日志匹配（Log Matching）**：AppendEntries 的一致性检查保证：若两日志在同一索引处任期相同，则该位置及之前的所有日志全部相同。 - **Leader 完整性（Leader Completeness）**：已提交的日志只会出现在后续任期的 Leader 上——由前两条加上“只提交当前任期”规则共同推出。 这三条环环相扣，最终保证核心承诺：**每台机器按相同顺序执行相同命令，已提交的命令永不丢失**。 ### 要点七：落地与生态 讲座收尾把镜头转向工业界：etcd、Consul、TiKV、CockroachDB 等系统都采用 Raft 或其变体，Kubernetes 的一切集群状态都存在基于 Raft 的 etcd 里。学员的 Lab 要用 Go 实现一个能通过线性一致性与宕机恢复测试的 Raft 库——这正是课程被称为“神课”的原因：不是听完就完，而是亲手把它造出来。 ## 知识与理论溯源 **复制状态机的思想源头**可追溯至 Leslie Lamport 1978 年的经典论文 "Time, Clocks, and the Ordering of Events in a Distributed System"（分布式系统逻辑时序的奠基之作）；而“用一组服务器互为备份跑状态机”的系统化表述，则见于 Lamport 后来的综述 "Implementing Fault-Tolerant Services Using the State Machine Approach"（1984/1998，ACM TOCS）。 **共识算法的谱系**：1988 年 Brian Oki 与 Barbara Liskov 发表的 Viewstamped Replication（VR）其实已经给出了与 Raft 高度同构的“选主+日志复制”方案，比 Paxos 正式发表还早十年——这也是为什么不少学者认为 Raft 在算法实质上更接近 VR 的直系后代。Lamport 的 "The Part-Time Parliament"（1998）以希腊岛议会寓言写成，艰深到多年无人引用，2001 年的 "Paxos Made Simple" 用一页纸重述，才让 Paxos 真正流行。 **FLP 不可能性定理**（Fischer、Lynch、Paterson，1985）：在纯异步系统中，不存在任何确定性共识算法能容忍哪怕一个节点故障。Raft 用随机化超时“以概率方式绕开”了这个理论墙——这与 Lamport 在 Paxos 中引入“优雅的议员”随机化是同一个思想传统。 **Raft 本尊**：Diego Ongaro 与其导师 John Ousterhout（斯坦福教授，Tcl 与 Redis 前身式人物，亦是 Berkeley BSD 研究时代的关键人物之一——此处仅指其学术履历）在 USENIX ATC 2014 发表 "In Search of an Understandable Consensus Algorithm"，获当届会议最佳论文奖（据论文页面与会议记录）。Ongaro 的博士论文 "Consensus: Bridging Theory and Practice"（2014）进一步补全了日志压缩、成员变更、Pre-Vote 防活锁等工程细节。论文中报告了一组可理解性对照实验：在斯坦福研究生课程中，多数学生学 Raft 后的测验表现优于学 Paxos（具体数据见论文第 9 节）。 **工程里程碑**：2013 年 CoreOS 开源 etcd，采用 Raft；2014 年 Google 发布 Kubernetes 并以 etcd 为存储中枢，让 Raft 事实上成为云原生时代的默认共识底座。HashiCorp 用自研的 hashicorp/raft 库支撑 Consul、Vault、Nomad；PingCAP 的 TiKV 用 Rust 重写了 etcd 的 Raft 实现（tikv/raft-rs）；MongoDB 在 4.0（2018 年）将副本集协议重写为 Raft 类算法（据 MongoDB 官方博客）。共识实现的“年度大考”则是 Kyle Kingsbury（网名 Aphyr）的 Jepsen 系列——历史上多个自称实现了 Raft 的系统在他的一致性测试中现出原形。 ## 批判性审查：哪些站得住，哪些要打折 **证据充分的部分**：Raft 的正确性论证在论文中有完整的不变量推导与 TLA+ 形式化规约（后由社区维护在 GitHub 的 tlaplus/raft 仓库），这是少数被形式化方法背书过、又被海量生产系统验证过的算法。其“可理解性”对照实验虽小，但方向性结论（Raft 更易学）在十年的教学实践中被广泛复现——6.824、各公司的内训课都把它当作共识入门首选，这本身就是最硬的证据。 **被夸大或有争议的部分**： 第一，“可理解性”能否作为学术贡献受到过质疑。有研究者指出 Paxos 难懂部分是叙述问题而非算法问题——剑桥的 Heidi Howard 等人在 2017 年提出 Flexible Paxos，证明 Paxos 的选举与提交多数派无需重合，说明 Paxos 体系本身仍有简化空间。Raft 的真正贡献与其说是新算法，不如说是**一次成功的知识产品化**：正确的抽象 + 完整的开源参考实现 + 可视化网站（raft.github.io）。 第二，强 Leader 模型有代价，论文对此着墨不多。所有写入都经 Leader 中转，意味着写入吞吐受单节点限制，且 Leader 切换时出现不可用的空窗期。Raft 优化的是“人理解的成本”，不是“系统的性能上限”——这是它与方法论上对立的算法（如无主的 EPaxos）最根本的取舍差异。 第三，“Raft 好实现”在工程上被打过脸。Jepsen 历史上多个基于 Raft 的系统暴露过一致性问题，问题几乎都不在核心协议，而在论文仅一笔带过的部分：日志快照与压缩、成员变更、只读请求的线性一致读。Ongaro 本人在博士论文里补充的 Pre-Vote、Check Quorum 机制，正是社区在真实故障（网络分区下的选举风暴）中踩坑后的产物。**核心协议教科书级完美，周边工程深坑遍地**——这才是对 Raft 更完整的认知。 第四，讲座形态的局限。课堂受时长所限，对成员变更（单步变更 vs 关节变更）、日志压缩（snapshot 何时触发）、客户端会话语义（重复请求去重）都只能点到为止。若只看视频就上手写生产系统，恰恰会栽在这些“视频没讲的部分”。这也是为什么 6.824 把 Lab 测试设计得如此凶残——用测试用例补齐课堂讲不到的边界。 ## 认知提升与实用启示 **第一，学算法先抄“不变量清单”，再抄流程图。** Raft 论文的正确性不是靠证明堆出来的，而是靠五条安全性质锚定的。读任何分布式算法，先把“系统永远满足什么”抄下来，再看机制如何服务这些不变量——顺序反过来，就会陷入“每一步都懂、合起来不懂”的困境。这个读法可以直接迁移到 Paxos、Zab、以及任何一致性协议的学习中。 **第二，动手前先玩 raft.github.io 的可视化，写代码前先读 etcd/raft。** 官方可视化网站可以逐票播放选举与复制过程，是建立直觉的最快途径；而 etcd 的 raft 库把核心协议压在几千行、零 I/O 的纯状态机代码里（网络与存储由使用者注入），是公认最适合精读的参考实现。自己从零实现用于学习很好，用于生产请直接用内嵌库——这一条是 Jepsen 报告们用真实事故换来的。 **第三，区分“共识保证”与“业务正确性”。** Raft 只保证所有节点按相同顺序应用相同日志，它不自动给你线性一致的读、不处理客户端重试的幂等、不解决脑裂期间对外的行为。工程师最容易犯的错，是把“我们用了 Raft”当作正确性免死金牌。正确的姿势是：共识层负责日志一致，应用层负责会话与语义——两层的设计责任要切开评审。 ## 视频论证结构图 ```mermaid flowchart TD A[分布式共识难题] --> B[Paxos正确但难懂] B --> C{能否造一个
可理解的算法} C --> D[Raft三招方法论] D --> D1[问题分解] D --> D2[强Leader模型] D --> D3[任期逻辑时钟] D1 --> E[Leader选举
随机超时拉票] D2 --> F[日志复制
多数派确认提交] D3 --> G[安全性不变量
选举限制与检查] E --> H[核心承诺
同序执行已提交不丢] F --> H G --> H H --> I[etcd与K8s等
生产系统落地] I --> J[启示
可读性即工程能力] ``` ## 延伸阅读 1. **Raft 官方网站与可视化（raft.github.io）** — 论文作者维护的交互式网站，可逐帧播放 Leader 选举与日志复制全过程，配合本文服用效果最佳。 2. **Diego Ongaro 博士论文 "Consensus: Bridging Theory and Practice"（2014，斯坦福）** — 比论文厚十倍的完整版：日志压缩、成员变更、Pre-Vote、性能评估全在其中，生产实现者必读。 ## 参考来源 1. [In Search of an Understandable Consensus Algorithm (Raft) — USENIX ATC 2014](https://raft.github.io/raft.pdf) — Raft 原始论文，本文所有机制细节与可理解性实验的出处 2. [Raft 官方网站](https://raft.github.io) — 论文、可视化演示、各语言开源实现汇总 3. [MIT 6.824 Distributed Systems 课程主页](https://pdos.csail.mit.edu/6.824/) — 讲座视频、讲义与 Go 语言 Lab（本文深读视频的官方课程页面） 4. [etcd — 分布式 KV 存储（GitHub）](https://github.com/etcd-io/etcd) — Kubernetes 背后的 Raft 落地实现，含可直接精读的 raft 核心库 5. [The Part-Time Parliament — Leslie Lamport, 1998](https://lamport.azurewebsites.net/pubs/paxos.pdf) — Paxos 原始论文，理解 Raft 所反对之物的第一手材料 --- > 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 > 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。