导读谷歌三大核心技术之一 GoogleFileSystem（一）

GoogleFileSystem设计构想

为满足Google数据处理的需求，Google工程师设计并实现了GoogleFileSystem（GFS）。GFS与传统分布式文件系统类似，也需要满足高性能、可伸缩性、可靠性以及可用性。与传统分布式文件系统思路不不同的是：

GFS认为组件失效是常态而非意外，GFS由大量廉价设备组成
文件数量异常巨大
绝大部分文件修改采用文件尾部追加数据而非覆盖原有数据
应用和文件系统协同设计

GFS架构设计

一个GFS包含一个单独的Master节点、多台Chunk服务器，并同时被多个客户端访问。

存储方式

GFS存储的文件被分割成固定大小的Chunk，Master分配给每个Chunk一个不变的64位唯一标识。每个Chunk备份到多个服务器上，以提高可靠性。

Master服务器

Master服务器管理所有Chunk的元数据，以管理各Chunk数据（类似于Linux文件系统的inode）。每个Chunk大小为64M，Chunk元数据大小为64字节，而且由于大多数文件包含多个Chunk因此可以将所有Chunk的元数据存储在Master的内存中，增强系统的简洁性、可靠性、高性能和灵活性。

Chunk信息

Master服务器不永久保存Chunk服务器有指定Chunk的副本的信息。因为在一个拥有数百台服务器的集群中，Chunk服务器加入集群、离开集群、更名、失效、以及重启的时候，Master服务器和Chunk服务器数据同步的问题会非常频繁。Master服务器在启动时候轮询Chunk服务器，并在之后定期轮询更新。

GFS的日志系统（灾备）

操作日志包含了关键的元数据变更历史记录。操作日志是元数据唯一的持久化存储记录，同时也是判断同步操作顺序的逻辑时间基线（类似LSN），必须确保日志文件的完整，确保只有在元数据的变化被持久化后，日志才对客户端是可见的。GFS把日志复制到多台远程机器，只有相应的日志记录写入到本地以及远程机器的硬盘后，才会响应客户端的操作请求。Master服务器会收集多个日志记录后批量处理，以减少写入磁盘和复制对系统整体性能的影响。

GFS灾难恢复

Master服务器在灾难恢复时，通过重演操作日志把文件系统恢复到最近的状态。为了缩短Master启动的时间，重演系统操作的日志量尽量的少。Master服务器在日志增长到一定量时对系统状态做一次Checkpoint（对数据库的快照）。在灾难恢复的时候，Master服务器就通过从磁盘上读取这个Checkpoint文件，以及重演Checkpoint之后的有限个日志文件就能够恢复系统。Checkpoint文件以压缩B-树形势的数据结构存储，可以直接映射到内存，在用于命名空间查询时无需额外的解析。Master服务器恢复只需要最新的Checkpoint文件和后续的日志文件。旧的Checkpoint文件和日志文件可以被删除。通常会多保存一些历史文件。Checkpoint失败不会对正确性产生任何影响，因为恢复功能的代码可以检测并跳过没有完成的Checkpoint文件。