一、GFS概述
1.1 什么是GFS
GFS（Google File System）是Google公司为了存储海量搜索数据而设计的专有分布式文件系统。它运行于廉价的普通硬件上，为大型、分布式的、对大量数据进行访问的应用提供服务，并具备高容错能力。
2003年，Google在SOSP（操作系统原理研讨会）上发表了GFS的论文，展示了一个运行在1000台以上服务器的分布式文件系统，这在当时是石破天惊的突破。
1.2 GFS的设计理念
GFS的设计与传统分布式文件系统有明显不同，主要基于以下核心假设：
| 设计假设 | 传统观念 | GFS观点 |
|---|---|---|
| 组件故障 | 视为异常 | 视为常态，必须自动容错 |
| 文件大小 | 小文件为主 | 大文件为主（GB级常见） |
| 数据修改 | 随机读写 | 主要是追加写入，很少覆盖 |
| 读取模式 | 随机小读 | 大规模流式读取 + 小规模随机读 |
| 延迟要求 | 低延迟优先 | 高吞吐量优先 |
1.3 关键设计特点
-
中心服务器模式：采用单个Master管理所有元数据，简化设计
-
控制流与数据流分离：Master负责元数据，ChunkServer负责数据，避免Master成为瓶颈
-
不缓存数据：因为数据量大、工作集太大，缓存收益甚微
-
大块设计 ：64MB的Chunk大小，远超传统文件系统
-
副本容错 ：默认3个副本，分布在不同ChunkServer上
-
宽松一致性模型：针对应用场景设计，不是强一致性
二、GFS架构
2.1 整体架构图
2.2 三大核心组件
(1) Client（客户端）
-
实现文件系统API，与Master和ChunkServer通信
-
缓存元数据（不缓存文件数据）
-
与Master交互仅限元数据操作，数据传输直接与ChunkServer通信
(2) Master（主服务器）
Master是GFS的核心管理节点，在逻辑上只有一个，负责维护所有元数据：
| 元数据类型 | 存储方式 | 说明 |
|---|---|---|
| 名字空间 | 内存 + 操作日志 | 文件和目录的树形结构 |
| 文件→Chunk映射 | 内存 + 操作日志 | 文件包含哪些Chunk |
| Chunk副本位置 | 仅在内存 | 通过心跳动态获取 |
重要特性：Master不持久化Chunk副本位置信息，而是在启动时向所有ChunkServer询问，并通过心跳保持更新。
(3) ChunkServer（数据块服务器）
-
将Chunk作为Linux文件存储在本地磁盘
-
默认每个Chunk保存3个副本
-
通过心跳向Master报告状态
三、Chunk设计
3.1 Chunk核心参数
| 参数 | 值 | 说明 |
|---|---|---|
| Chunk大小 | 64MB | 远大于传统文件系统 |
| Chunk标识 | 64位全局唯一ID | 由Master在创建时分配 |
| 默认副本数 | 3个 | 可配置 |
3.2 大块设计的优势
-
减少Client与Master交互：读写同一Chunk只需一次元数据请求
-
减少网络负载：Client可与ChunkServer保持较长时间TCP连接
-
减少元数据规模：Master内存可容纳全部元数据
3.3 大块设计的劣势
-
小文件可能成为热点：一个小文件只占一个Chunk，大量Client访问同一Chunk会导致该ChunkServer过载
-
但在Google的实际应用中，应用程序通常顺序读取包含多个Chunk的大文件，这不是主要问题
四、读写流程
4.1 读取流程
关键点：
-
步骤1-4仅在第一次访问该Chunk时发生
-
Client缓存元数据，后续读取直接与ChunkServer通信
4.2 写入流程
GFS采用主备复制（Primary/Secondary） 协议：
关键点：
-
Primary负责确定所有写入的顺序
-
数据流与控制流分离：数据先推送到所有副本，再由Primary排序执行
五、容错机制
5.1 Master容错
Master存储的元数据容错策略：
| 元数据类型 | 容错方式 |
|---|---|
| 名字空间 | 操作日志 + Checkpoint，多副本存储 |
| 文件→Chunk映射 | 操作日志 + Checkpoint |
| Chunk副本位置 | 启动时重建 + 心跳更新 |
高可用措施：
-
操作日志：持久化到本地磁盘 + 远程副本
-
Checkpoint：定期创建，加速恢复
-
Backup Master：同步复制，作为热备
-
影子Master：异步复制，分担读压力
5.2 ChunkServer容错
-
副本机制 ：每个Chunk默认3个副本，分布在不同机架
-
心跳检测：Master定期与ChunkServer通信，检测故障
-
自动恢复：某副本丢失时，Master自动复制新的副本
-
数据完整性：每个64KB Block有32位校验和，检测数据损坏
5.3 数据完整性保证
6.3 Record Append语义
GFS专门设计的Record Append操作：
8.1 架构对比
| 特性 | GFS | HDFS | GlusterFS |
|---|---|---|---|
| 架构类型 | 中心化（Master-Slave） | 中心化（NameNode-DataNode） | 去中心化 |
| 数据定位 | Master查询 | NameNode查询 | DHT算法计算 |
| 数据块大小 | 64MB | 64MB/128MB | 可变 |
| 默认副本数 | 3 | 3 | 可配置 |
8.2 适用场景对比
| 场景 | GFS | HDFS | GlusterFS |
|---|---|---|---|
| 大数据批处理 | ✓ 优秀 | ✓ 优秀 | ○ 一般 |
| 大文件存储 | ✓ 优秀 | ✓ 优秀 | ✓ 优秀 |
| 小文件处理 | △ 一般 | △ 一般 | ✓ 较好 |
| 低延迟访问 | ✗ 不适合 | ✗ 不适合 | ○ 一般 |
| 云原生部署 | ✗ 专有系统 | ○ 支持 | ✓ 优秀 |
七、性能与局限性
7.1 性能数据
根据GFS论文，集群A的性能表现：
| 指标 | 性能 |
|---|---|
| 读取吞吐量 | 94 MB/s（16客户端+16ChunkServer） |
| 接近饱和 | 1 Gbit/s网络的理论极限 |
| 集群A总吞吐 | 500 MB/s（在当时是巨大规模） |
7.2 GFS的局限性
| 局限性 | 说明 |
|---|---|
| 单Master瓶颈 | 内存和CPU可能成为限制 |
| 小文件效率低 | 大量小文件会增加元数据开销 |
| 缺乏自动故障转移 | Master故障需要人工干预 |
| 宽松一致性 | 应用需要处理不一致和重复数据 |
| 不是POSIX兼容 | 只提供专用接口 |
八、GFS vs HDFS vs GlusterFS
-
每个Chunk划分为64KB Block ，每个Block有32位校验和
-
读取时验证校验和，发现错误则从其他副本读取
-
检测到错误后，Master会克隆正确的副本到新的ChunkServer
六、一致性模型
6.1 一致性定义
| 术语 | 定义 |
|---|---|
| 一致 | 所有客户端从任何副本读到相同的数据 |
| 已定义 | 一致 + 客户端能看到写入的全部数据 |
6.2 一致性状态
| 操作类型 | 结果状态 |
|---|---|
| 无并发写入 | 已定义（所有客户端看到相同数据） |
| 并发写入成功 | 一致但不定义（可能看到部分混合数据） |
| 写入失败 | 不一致 |
示例：两个客户端并发写入同一区域
-
C1写入"ab"，C2写入"xy"
-
所有客户端可能都看到"xb"（混合结果）
-
但所有客户端看到的相同 ，所以是一致的
-
"至少一次"语义：数据可能被写入多次（重复记录）
-
返回实际写入的偏移量给客户端
-
应用程序负责处理重复数据（如使用唯一标识去重）