一、GFS的设计目标与假设
Google File System（GFS）是Google在2003年发表的开创性分布式文件系统论文中描述的系统。它专为Google的核心业务场景设计——存储爬虫抓取的网页内容、搜索引擎的倒排索引、用户行为日志等海量数据。
GFS的设计建立在一系列明确的目标和假设之上。第一，系统由数千台廉价PC组成，硬件故障是常态。磁盘损坏、网络断开、电源故障等都是日常事件，系统必须内置容错机制。第二，系统存储少量的大文件，典型大小在数百MB到数GB，小文件也支持但未做特别优化。第三，文件主要被大块顺序读取（数百KB到MB级别的读取）和追加写入（Append），随机写入极其罕见。第四，文件写入通常是大量数据的一次性追加，写入后很少修改。第五，系统需要支持高吞吐量的并发追加写——多个客户端可能同时向同一个文件追加数据。第六，高带宽比低延迟更重要——Google的批处理任务（如MapReduce）更关注整体吞吐量而非单次操作的延迟。
二、GFS的架构
GFS采用单一Master加多个ChunkServer的架构，这个设计影响了后续几乎所有分布式文件系统（包括HDFS）。
Master：GFS集群只有一台Master（可以有多台Shadow Master作为热备）。Master维护所有文件系统的元数据，包括：文件和Chunk的命名空间、文件到Chunk的映射关系、每个Chunk副本的物理位置。Master不存储任何实际的数据块——所有数据都在ChunkServer上。Master将元数据全部保存在内存中（约64字节元数据对应一个64MB的Chunk），这使得Master可以快速响应客户端的元数据查询请求。以64MB的Chunk大小计算，如果Master有64GB内存，可以管理约64PB的数据（100万个Chunk）。元数据通过操作日志（Operation Log）持久化到磁盘并复制到远程机器，保证Master故障后可恢复。
ChunkServer：集群中有数百到上千个ChunkServer，每个ChunkServer运行在普通的Linux机器上。ChunkServer将Chunk存储为本地文件系统中的普通文件（Linux的ext3/ext4）。每个Chunk被复制到多个ChunkServer上（默认三副本），分布在不同的机架上。
Chunk：GFS将文件切分为固定大小的Chunk（64MB，HDFS默认为128MB）。每个Chunk由一个全局唯一的64位Chunk Handle标识，由Master在Chunk创建时分配。Chunk大小是一个关键的设计权衡：Chunk越小，文件被划分得越细，同一文件的读取可以跨越更多的ChunkServer获得更高的并行度；但Chunk越大，Master需要管理的元数据越少，客户端与Master的交互频率越低（因为一个Chunk足够大，客户端可以在一个Chunk内完成大量操作而不需要再次访问Master）。
选择64MB这样一个远大于传统文件系统块（Linux的4KB）的块大小，基于如下考虑：减少Master元数据规模（PB级数据也只需要百万级别的Chunk）；减少客户端与Master的交互次数（客户端可以在与Master的一次交互后，缓存Chunk位置信息，完成大量的顺序读写）；将网络开销分摊到大的数据块传输上。
客户端：GFS客户端是链接到应用程序的库。客户端与Master交互只做元数据操作（如打开文件、获取Chunk位置），所有数据读写直接与ChunkServer交互，Master不会成为数据流量的瓶颈。客户端会缓存从Master获取的元数据，避免频繁的Master交互。
三、读操作流程
客户端读取GFS文件的流程设计得非常精简，最大化数据吞吐量：
第一步，客户端将文件名和要读取的字节偏移量转换为文件内的Chunk索引（chunk_index = byte_offset / 64MB）。客户端向Master发送请求，包含文件名和Chunk索引。
第二步，Master返回该Chunk的Handle以及所有副本所在的ChunkServer地址列表。Master按某种策略（通常是网络距离最短）对ChunkServer排序。
第三步，客户端缓存这些位置信息（以备后续读取同一Chunk的其他部分），然后向最近的ChunkServer发送读取请求。读取请求包含Chunk Handle和字节范围。
第四步，ChunkServer从本地磁盘读取数据返回给客户端。
如果读取量超过一个Chunk的边界，客户端会在内部拆分为多个Chunk的读取请求，可以并发向不同的ChunkServer发出。
后续对同一Chunk的读取不需要再联系Master，直到缓存的信息过期或者Chunk被重新分配。这大大减少了Master的负载——在典型的读取工作负载中，超过99%的读取操作不需要与Master交互。
四、写操作与租约机制
GFS的写入设计是其最独特的特性。为了在保持多副本一致性的同时避免Master成为瓶颈，GFS引入了租约（Lease）机制。
对于每次Mutation操作（写入或追加），Master将租约授予某个Chunk的某个副本，该副本成为临时的“主副本”（Primary）。Primary对此次Mutation的所有副本更新进行排序。租约初始有效期为60秒，Primary可以通过心跳续约。如果Master与Primary失去联系，租约到期后Master可以安全地将租约授予另一个副本。
写入流程（以三副本为例）：
第一步，客户端向Master询问当前哪个ChunkServer持有该Chunk的租约，以及其他副本的位置。如果当前没有租约持有者（首次写入该Chunk），Master选择一个副本授予租约。
第二步，Master返回Primary和Secondary的身份信息给客户端。客户端缓存这些信息。
第三步，客户端将数据推送到所有副本（Primary和所有Secondary）。这一步只是将数据暂存到ChunkServer的内存缓冲区中，不实际写入磁盘。客户端按网络距离排序推送，可以以流水线方式（Pipeline）进行——客户端将数据发送给最近的副本S1，S1在接收的同时转发给S2，S2转发给S3。这样充分利用了每个机器的出站带宽。
第四步，所有副本确认数据接收后，客户端向Primary发送写请求。Primary为这个写操作分配一个序列号，将序列号应用到本地状态，然后将写请求（连同序列号）转发给所有Secondary。
第五步，所有Secondary完成写操作后，向Primary回复确认。Primary统计回复结果，向客户端返回操作结果。如果任何Secondary写入失败（如磁盘满或宕机），Primary向客户端返回错误。客户端收到错误后重试（从第一步重新开始）。注意，这时失败副本上的数据处于不一致状态，但GFS并不立即修复，而是在后续的正常写入中通过Chunk版本号（Chunk Version Number）检测并处理。
这个流程的关键设计在于数据流与控制流的分离：数据从客户端按流水线方式推送到所有副本，控制流从客户端到Primary再到Secondary。这使得数据可以按网络拓扑最优的路径传输，而控制流则按租约授权链传递。
五、原子追加记录
GFS提供了一个特殊的写入原语：原子追加记录（Atomic Record Append）。在原子追加中，客户端只需指定要写入的数据，GFS原子地将数据追加到文件的末尾，并返回写入的偏移量。这对于多客户端并发写入同一文件（如多个MapReduce任务并发写入同一个输出文件）至关重要——客户端不需要协调“谁写到哪个偏移量”。
原子追加的实现：客户端将数据推送到Chunk的所有副本，然后向Primary发送追加请求。Primary检查追加数据是否会导致Chunk超过最大大小（64MB）。如果超出，Primary先将当前Chunk填充到满（填充的是客户端数据的一部分或仅是填充字节），然后要求所有Secondary也做同样操作，回复客户端该Chunk已满，客户端应在下一个Chunk上重试。如果未超出，Primary将数据写入当前末尾位置，要求所有Secondary在相同偏移量写入相同数据。只要有至少一个副本成功写入（通常至少需要法定数量的副本），操作就成功。
原子追加的一个微妙特性是：在失败重试的情况下，可能导致文件中出现重复记录或填充字节。GFS的论文明确指出，原子追加保证数据被至少写入一次（At-Least-Once），且写入到文件末尾的某个偏移量（偏移量由GFS选择），但不保证字节级别的幂等——失败的追加可能被重试，导致相同数据在文件中出现多次。应用程序必须能够处理这些情况，例如在数据记录中包含校验和或唯一标识符以便在读取时去重。
六、垃圾回收
GFS没有采用传统的即时删除机制，而是采用惰性垃圾回收（Lazy Garbage Collection）。当用户删除一个文件时，Master立即将文件重命名（在命名空间中添加删除时间戳），使其对普通文件操作不可见。经过一定的保留期（默认三天），Master在定期的后台扫描中真正删除这些文件，回收其Chunk。这种设计简单而健壮——即使客户端误删文件，在保留期内仍可通过重命名恢复；也避免了ChunkServer因网络问题暂时不可达时误判Chunk为孤儿而错误回收。
对于因写入失败或ChunkServer失联而产生的孤儿Chunk（Master的元数据中不再引用的Chunk），Master通过定期的心跳交互收集每个ChunkServer持有的所有Chunk信息，对比元数据识别出孤儿，向ChunkServer发送删除指令。
七、高可用与数据完整性
Master的高可用：Master的元数据通过操作日志持久化。每次元数据变更（如创建文件、创建Chunk）都先写入本地磁盘的操作日志，然后批量复制到远程的备份机器上。只有当操作日志在本地磁盘和远程副本上都持久化后，Master才向客户端确认操作成功。Master定期创建检查点（Checkpoint），将当前完整的命名空间状态序列化到磁盘（类似数据库的全量备份+增量日志）。Master故障恢复时，加载最近的检查点，然后重放检查点之后的操作日志。
阴影Master（Shadow Master）提供只读的元数据访问，在Master故障时提供降级服务。Shadow Master通过滞后地重放操作日志来保持与Master的状态同步（通常滞后数百毫秒到数秒）。
ChunkServer的高可用：Chunk的多个副本分布在不同的机架上（机架感知放置策略）。如果一个机架的网络交换机故障，其他机架上的副本仍然可用。Master定期扫描所有Chunk的副本状态，如果某个Chunk的副本数低于阈值（如2），自动触发再复制——选择其他ChunkServer创建新的副本。
快速恢复：GFS设计为在秒级内从节点故障中恢复。ChunkServer可以将自身状态（哪些Chunk存在本地）通过心跳报告给Master。即使ChunkServer整体重启（而非磁盘损坏），它在重启后立即向Master报告其Chunk列表，Master更新元数据，系统快速恢复正常。这与传统RAID需要数小时的磁盘重建形成鲜明对比。
数据完整性：GFS使用校验和（Checksum）检测数据静默损坏。每个64KB的数据块有一个32位的校验和（CRC-32C），存储在ChunkServer的内存中，也随日志持久化。ChunkServer在读取数据时验证校验和，如果发现不匹配，向客户端返回错误，客户端转而从其他副本读取。Master随后安排该损坏Chunk的再复制。对于空闲的Chunk，ChunkServer定期扫描和校验，及时发现静默损坏。
八、GFS的局限与HDFS的改进
GFS的设计深刻地影响了Hadoop的HDFS，但HDFS也做了一些重要改进。HDFS将Chunk大小从64MB增加到128MB（可配置），进一步减少了元数据规模。HDFS支持异构存储（内存、SSD、HDD、归档存储四层），可以按数据温度分层存储。HDFS NameNode支持高可用（Active/Standby模式），通过共享的编辑日志（JournalNode集群）实现，比GFS的Shadow Master方案严格性更高。HDFS支持联邦（Federation），多个NameNode各自管理一部分命名空间，解决了单一Master的内存瓶颈。HDFS的权限模型比GFS更丰富（POSIX风格的文件权限+ACL）。
然而，无论是GFS还是HDFS，都存在一个根本性局限：单一Master架构。虽然Master从不处理数据流（不存在数据吞吐瓶颈），但Master的内存仍然是命名空间大小的硬限制。HDFS Federation虽然通过多NameNode部分缓解了这个问题，但每个分区的命名空间仍然是单一Master管理的。新一代的分布式文件系统（如Ceph、MinIO）采用无Master或伪去中心化架构，从根本上消除了这个瓶颈。
九、面试常见追问
问题一：为什么GFS的Chunk大小选择64MB而非更小或更大？
这是权衡的结果。当时典型的读取模式是数百MB到数GB的顺序扫描（MapReduce输入），更大的Chunk意味着客户端可以在与Master一次交互后读取更多数据，TCP连接的启动开销被分摊到更多数据上，从而实现更高的吞吐量。更大的Chunk还减少了Master的元数据量（同样的总存储量需要更少的Chunk）。但Chunk过大会导致负载不均衡——如果一个热门文件只有一个Chunk（因为文件本身就小于64MB），所有对该文件的读取都会打到同一个ChunkServer上，成为热点。Google的实践表明，某些包含中间数据的可执行文件或小的文本文件确实会变成热点，解决方案是提高这些文件的复制因子。
问题二：GFS的一致性模型是怎样的？
GFS提供的是宽松的一致性模型（Relaxed Consistency）。对于命名空间操作（如创建文件、重命名），GFS提供原子性和正确性保证（通过Master集中管理和操作日志）。对于数据操作：如果一次写入成功且没有并发写入，所有副本在字节级别一致；如果并发写入成功，所有副本在字节级别可能不一致（即不同副本在相同偏移量上可能包含不同的数据）。原子追加保证数据至少被写入一次，字节内容在所有副本一致，但可能包含重复或填充内容。应用程序需要适应这种宽松的一致性：使用校验和验证数据完整性；使用唯一ID识别记录以处理重复；写入时使用追加而非覆盖。
问题三：GFS如何处理热点问题？
当某个Chunk被大量客户端同时读取时（如MapReduce的可执行文件、共享库等），存储该Chunk的ChunkServer会成为瓶颈。GFS的解决方案包括：（1）增加热点Chunk的副本数，通过更高的复制因子（如10或更多）分散读流量；（2）客户端缓存读取的数据，减少对ChunkServer的压力——可执行文件通常会被客户端缓存；（3）在调度MapReduce任务时，注意分散依赖相同输入Chunk的任务（数据本地性调度已经自然地做到了这一点）。
