很多人对分布式系统的第一次挫败感，来自面试里那句「说说 GFS 的写入流程」。背了三段式，被追问「为什么 chunk 是 64MB 不是 128MB」「租约到底解决什么问题」就卡住。这门课不是带你从零造一个文件系统，而是把 GFS 这篇 2003 年的论文拆成能讲清楚、能画出来、能被追问的颗粒度。两节课，不绕路。

先测一下：这几个问题你能答上来几个

在点开之前，先自评。如果你能顺畅回答下面任意三条，这门课对你可能偏浅，可以直接跳到最后的练习部分自测：

GFS 的单 Master 为什么没有成为写入瓶颈，读和写分别走了什么路径？
Chunk Server 上的 64MB chunk 是怎么定的？这个数字变大变小分别带来什么代价？
租约（lease）机制里，主副本和 Master 各自负责什么，租约过期会发生什么？
记录追加（record append）和普通写入的差别在哪，为什么它需要「至少一次」语义？
快照（snapshot）为什么用 copy-on-write，它和写时复制的文件系统有什么异同？

卡住的地方，就是这两节课要补的位置。GFS 的价值不在于它今天还在被直接使用，而在于它是理解 HDFS、对象存储、以及后续 Colossus 演进思路的起点。跳过它去学上层框架，很多设计取舍会变成「规定」而不是「理由」。

课程实际覆盖的能力缺口

第一个缺口是架构直觉。多数资料只告诉你 GFS 有 Master、Chunk Server、Client 三种角色，但不讲清楚为什么容错要靠「把组件做简单 + 大量冗余」而不是靠复杂协议。课里会把单点故障、心跳、版本号这些机制串成一条线，让你自己推导出「为什么 Master 的内存能装下整个命名空间」。

第二个缺口是读写路径的细节。客户端拿数据不经过 Master，这个结论人人都知道，但控制流和数据流分离之后，一致性模型怎么保证、追加写为什么会出现重复记录，这些才是工程上的真问题。课程会用具体的数据流图把这条链路走一遍。

第三个缺口是从论文到系统设计。课程包含系统设计 Mock 环节，也就是拿 GFS 的设计约束（大文件、追加为主、顺序读多）去反推：如果换成小文件场景、低延迟场景、强一致场景，哪些设计会崩，需要怎么改。这一步是把「读懂」变成「能用」的关键。

配套练习怎么用

资料包里的练习不是选择题。建议按这个顺序做：先不看答案画一遍 GFS 的写入时序图，标出每一步谁在等谁；然后针对「租约续约失败」这一个异常点，写出系统的恢复动作；最后拿一道设计题做迁移，比如把 GFS 的假设改掉一条，说明架构要动哪里。

画图练习重点在数据流和控制流是否分开画清楚。
异常推演重点在能否说出「谁先发现、谁先动作」。
设计迁移重点在能不能明确说出哪条假设被破坏了。

做完再看讲解，对照的是推理链有没有断，而不是结论对不对。GFS 的很多细节论文里写得并不完整，课里会点出哪些地方是工程惯例补上的，哪些是原论文的模糊地带——这些恰恰是面试里能拉开差距的地方。

两节课结束后，你应该能回答

不是「我了解了分布式文件系统」，而是具体到能对着白板讲：GFS 为什么选择弱一致性模型而不是强一致，代价由谁承担；Master 的故障恢复涉及哪些持久化状态；以及最关键的，如果让你为今天的场景重新设计一个 GFS，你会保留什么、砍掉什么、换成什么。

最后一句提醒：GFS 是 2003 年的系统，论文里的硬件假设（便宜的商用机、网络带宽远小于磁盘带宽）和今天差别很大。学它的目的不是照搬，而是掌握「从约束推导设计」的方法。带着这个视角去听，两节课的密度会比你预期的高。