案例库 · 工程与运营 · 技术决策 · 2003–2010
谷歌文件系统视磁盘崩溃为常态，在廉价机器上扩展
GFS将文件分割成64MB块，每块三个副本，并让追加操作原子化——在普通服务器上存储数百TB数据。
解法
谷歌的爬虫和索引器产生的数据量超出了单一可靠服务器能存储的范围，而硬件集群经常发生故障。早期的分布式文件系统假定组件大多正常；GFS则假定它们会出问题。
2003年的SOSP论文描述了GFS：文件被分成64MB的块，每个块在三个块服务器上复制，有一个主服务器负责元数据、租约和垃圾回收，而客户端直接移动数据。由于追加操作而非重写占主导，记录追加被设计为原子操作，使多个生产者无需锁即可写入同一文件。
当时最大的集群在超过一千台机器上的数千个磁盘上存储了数百TB数据，服务数百个客户端。GFS成为MapReduce和Bigtable底下的存储层，其设计在开源Hadoop栈中被重新实现为HDFS。
生效的原因
- 三副本复制将磁盘丢失变成常规修复事件。
- 单一主服务器简化了放置、租约和垃圾回收。
- 64MB块摊销网络开销并缩小元数据。
- 原子追加使数千生产者在无锁情况下共享文件。
取得的成效假设故障会发生；廉价复制神来之笔
可借鉴之处
如果硬件频繁故障，就别买可靠硬件了：设计让复制和重试成为常规路径，并让常见写入（追加）原子化，而不是让每个操作都健壮。
后续进展
GFS运行谷歌数据管道多年，并启发了HDFS——支撑了谷歌外大数据第一个十年的Hadoop生态系统的存储层。其架构至今仍是复制型、追加密集型存储系统的模板；谷歌后来将其演化为具有分布式元数据的Colossus。
资料来源
发现哪里写错了？告诉我们。