【存储】漫谈 Google File System（GFS）中篇：GFS 是怎么设计的？—— 架构与核心机制详解
在上篇中，我们理解了 Google 为什么需要 GFS：面对海量数据、廉价硬件和特殊访问模式，传统文件系统已力不从心。
现在，我们深入 GFS 的内部，看它如何通过精巧的架构设计，实现高吞吐、高可用、强扩展性的目标。
1. 整体架构：Master + Chunk Servers + Clients
GFS 采用经典的中心化控制 + 分布式存储架构，由三类角色组成：
全屏复制
| 组件 | 职责 |
|---|---|
| Master（主节点） | 管理整个文件系统的元数据：文件名到 Chunk 的映射、Chunk 副本位置、租约管理、垃圾回收等。通常只有一个活跃 Master（可配热备）。 |
| Chunk Server（块服务器） | 存储实际数据。每个文件被切分为固定大小的Chunk（默认 64MB），每个 Chunk 以 Linux 文件形式存储在本地磁盘。 |
| Client（客户端） | 应用程序通过 GFS Client 库与系统交互。Client不经过 Master 读写数据，只向其查询元数据。 |
关键思想：控制流走 Master，数据流直连 Chunk Server—— 避免 Master 成为性能瓶颈。
2. 文件组织：Chunk 机制
- 每个文件被逻辑切分为固定大小的 Chunk（64MB）。
- 每个 Chunk 有一个全局唯一的Chunk Handle（64位 ID）。
- 每个 Chunk 默认在不同机器上保存 3 个副本（可配置），实现容错。
为什么是 64MB（远大于传统文件系统的 block size）？
- 减少 Master 元数据量（1PB 数据 ≈ 1600 万个 Chunk，元数据可全内存缓存）
- 降低 Client 与 Master 的交互频率
- 更适合大文件顺序读写场景
3. 元数据管理：Master 的三大职责
Master 存储三类关键元数据（全部常驻内存，定期 checkpoint 到磁盘）：
文件命名空间 & 文件到 Chunk 的映射
（例如：/logs/app.log→ [Chunk1, Chunk2, ...]）每个 Chunk 的副本位置
（注意：副本位置不持久化！Master 启动时通过心跳从 Chunk Server 获取）租约（Lease）信息
—— 这是 GFS 实现并发写一致性的核心机制（下文详述）
Master 不参与数据传输，因此即使单点，也能支撑大规模集群（Google 当年部署数千台 Chunk Server）。
4. 写操作：如何支持高并发追加？
GFS 主要优化追加写（append），而非随机写。典型场景：多个生产者同时向一个日志文件追加记录。
关键机制：租约（Lease） + Primary Replica
当 Client 要写一个 Chunk：
- 向 Master 查询该 Chunk 的副本位置及当前Primary（主副本）
- Master 会为该 Chunk 授予一个租约（默认 60 秒），指定一个 Primary
- Client 将数据并行推送给所有副本（包括 Primary）
- 所有副本收到后，Primary 决定写入顺序，并通知其他副本按相同顺序写
- Primary 返回成功给 Client
这样既保证了写操作的原子性和顺序一致性，又避免了 Master 参与每一次写。
⚠️ 注意：GFS 不保证字节级一致性，但保证至少一次追加成功（可能有少量重复或填充空洞），应用需容忍。
5. 读操作：高效且容错
- Client 向 Master 查询文件偏移量对应的 Chunk 及其副本位置
- Master 返回副本列表（通常按网络拓扑排序，优先返回同机架节点）
- Client直接连接最近的 Chunk Server读取数据
- 若某副本不可用，Client 自动尝试其他副本
读路径完全绕过 Master，实现高吞吐。
6. 容错机制：故障是常态
GFS 假设组件随时可能失效，因此设计了多重容错：
- Chunk 多副本：默认 3 副本，跨机器甚至跨机架存放
- Master 状态持久化：操作日志（operation log）+ checkpoint，支持快速恢复
- 心跳检测：Chunk Server 定期向 Master 发送心跳，报告存活状态和 Chunk 信息
- 自动复制：Master 发现副本数不足时，自动从健康副本复制新副本
- 快照（Snapshot）：通过 Copy-on-Write 实现轻量级文件克隆，用于备份或实验
7. 为什么这样设计？—— 设计权衡（Trade-offs）
GFS 的设计处处体现“为特定 workload 优化”的思想：
全屏复制
| 设计选择 | 原因 |
|---|---|
| 中心化 Master | 简化一致性管理；元数据小，可全内存；控制流轻量 |
| 大 Chunk（64MB） | 减少元数据、降低交互频次、适配大文件顺序访问 |
| 租约机制 | 在无 Master 参与下实现并发写的一致性 |
| 放弃 POSIX 语义 | 不支持文件锁、随机写、强一致性，换取简单性和性能 |
| 应用层容忍不一致 | 允许追加写有空洞或重复，由上层（如 MapReduce）处理GFS 的哲学：不做通用系统，而做“刚好够用”的专用系统。 |
小结
GFS 通过“Master 控制 + Chunk 分布存储 + 租约协调 + 多副本容错”的架构，在廉价硬件上构建了一个高吞吐、高可用、可扩展的分布式文件系统。它的设计不是追求理论完美，而是紧密贴合 Google 内部大数据批处理的实际需求。
这种“务实、简化、容错优先”的思路，深刻影响了后来的 HDFS、Ceph、以及云存储系统。
预告：在下篇，我们将探讨 GFS 的实际效果、局限性及其对后续系统的影响，并回答：“GFS 今天还重要吗？”
敬请期待:【存储】漫谈 Google File System（GFS）下篇：GFS 的影响、局限与遗产 —— 一个时代的奠基者