《The Google File System》论文研读笔记

基本介绍：GFS是一种面向大规模数据密集型应用的分布式文件系统，不仅具有以前分布式系统的许多特性如高性能、伸缩性、可用性、可靠性，而且又结合了现在工作的需求以及未来发展的需要重新定义了文件的系统，主要包括：

• 因为 GFS 使用设备数多，将组件失效视为常态事件 。因此 持续监控 、错误检测 、灾难冗余 和 自动恢复 的机制必须包括在 GFS 中 。
• 主要对大文件的管理进行了优化 。我们都知道，处理一个大文件所用的时间远远低于处理同样大小的许多小文件。比如1GB的游戏文件，删除它会很快，而1GB的10000个图片文件，删除它会很耗时。我们的网络文件就是一堆小文件组成的，对于I/O来说，处理这些文件会很耗时，从这方面GFS也做出了改进。
• 主要应用于 对文件尾部追加数据 的修改，而非覆盖原有数据的方式，如 “生产者-消费者” 队列，或者其他多路文件合并操作 。一旦写完后，对文件的操作通常是顺序读 。
• 采用了较弱的 一致性 要求，引用 原子性的记录追加 操作，保证多个客户端能够同时进行追加操作，不需要额外的同步操作来保证数据的一致性 。
• 目标程序绝大多数要求高速率、大批量地处理数据，极少要求对单一读写操作有严格的响应时间要求 。即 高性能的稳定网络带宽 比 低延迟 更重要 。 

  GFS的架构由一个master node 和一群node连接，主节点保存各个分节点的各种信息，并且用“心跳周期”与每个节点联系。同时GFS提供了一套类似传统文件系统的 API接口函数 ，文件以 分层目录 的形式组织，用 路径名 来标识 。支持：创建新文件、删除文件、打开文件、关闭文件、读和写文件，以及快照和记录追加操作 。

  GFS采用单一主服务器。这样会降低系统复杂性，但是主服务器不能限制整个服务的性能，因此主服务器的读写操作就要少。

  GFS分为三种节点：master server，chunk server和client。其中master存在的目的是管理chunk，chunk存在的目的是存储文件，client存在的目的是与chunk交互信息，并与master传递少量管理信息。因此GFS就采用64MB作为块的尺寸，这样不仅能够避免空间碎片化，而且能够快速定位。同时能够保持更多的TCP连接。

  在系统的交互上，可以更改顺序，更改是对数据及内容的修改（包括覆盖和追加操作），每次的操作是作用于块。为了保持顺序的一致性，使用租赁规则。

  最后，GFS 为解决崩溃和错误采用容错与诊断使用快速恢复和复制解决崩溃问题。快速恢复就是反复访问重新连接。复制分为chunk复制和master复制。chunk的复制要注意复制到不同机架，以免机架受损导致的数据丢失。Master服务器所有的操作日志和checkpoint文件都被复 制到多台机器上。一个 Master服务进程负责所有的修改操作，包括后台的服务，比如垃圾回收等改变系统内部状态活动。当它失效的时，几乎可以立刻重新启动。此外，GFS中还有些“影子”Master服务器，这些“影子”服务器在“主”Master服务器宕机的时候提供文件系统的只读访问。它们是影子， 而不是镜像，所以它们的数据可能比“主”Master服务器更新要慢。“影子”Master服务器在启动的时候也会从Chunk服务器轮询数据（之后定期拉数据），数据中 包括了Chunk副本的位置信息；“影子”Master服务器也会定期和Chunk服务器“握手”来确定它们的状态。在主Master服务器因创建和删除 副本导致副本位置信息更新时，“影子”Master服务器才和主Master服务器通信来更新自身状态。
  数据完整性。每个chunk都要维持一个check，就是校验。他会维持副本的完整性，当发现不一致的时候，会告诉master，master从其他正确副本复制给chunk。复制完之后，chunk把错误副本删掉。
  诊断工具。 主要是诊断日志记录，对性能影响很小。