如果你只打算学一个分布式系统算法，那应该是 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 的讲师强调了一个课堂事实：这是分布式系统课程中最难的一讲，也是工业界用得最多的一讲。
算法史上不是没有答案——Leslie Lamport 的 Paxos 从 1998 年正式发表（"The Part-Time Parliament"）到 2001 年用白话重写（"Paxos Made Simple"），几乎垄断了共识领域十几年。Google Chubby、Spanner 都基于 Paxos 变体。
但讲座转述了 Raft 作者团队的判断，这也是整个研究故事的戏剧性所在：Paxos 正确，但难教、难学、更难实现。它的描述方式是“先给出一个单决策（single decree）的算法，再拼装成多决策系统”，而这个拼装过程论文从未真正完成；它的正式证明与工程实现之间隔着一道鸿沟，导致每个 Paxos 实现都是从零摸索，且彼此不兼容。Raft 论文原话的潜台词是：为一个难懂的正确性买单，不值得。
Raft 的方法论极其工程化，讲座把它概括为三招：
第一招，问题分解。 把共识拆成三个相对独立的子问题：Leader 选举、日志复制、安全性约束。每个子问题可以单独理解、单独测试。
第二招，减少需要考虑的状态。 引入强 Leader 模型：所有日志只能从 Leader 流向 Follower，数据单向下发。你不需要在脑中同时推演多节点各自决策的排列组合。
第三招，化不确定性为确定性。 用逻辑时钟“任期（term）”给时间切片：每个任期最多一个 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 论文列出五条安全性质，讲座重点讲了其中三条：
这三条环环相扣，最终保证核心承诺：每台机器按相同顺序执行相同命令，已提交的命令永不丢失。
讲座收尾把镜头转向工业界：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”当作正确性免死金牌。正确的姿势是：共识层负责日志一致，应用层负责会话与语义——两层的设计责任要切开评审。
flowchart TD
A[分布式共识难题] --> B[Paxos正确但难懂]
B --> C{能否造一个<br/>可理解的算法}
C --> D[Raft三招方法论]
D --> D1[问题分解]
D --> D2[强Leader模型]
D --> D3[任期逻辑时钟]
D1 --> E[Leader选举<br/>随机超时拉票]
D2 --> F[日志复制<br/>多数派确认提交]
D3 --> G[安全性不变量<br/>选举限制与检查]
E --> H[核心承诺<br/>同序执行已提交不丢]
F --> H
G --> H
H --> I[etcd与K8s等<br/>生产系统落地]
I --> J[启示<br/>可读性即工程能力]
本文由「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 等场景全覆盖。