作者：刘旭晖 Raymond 转载请注明出处
Email：colorant at 163.com
BLOG：http://blog.csdn.net/colorant/
更多论文阅读笔记 http://blog.csdn.net/colorant/article/details/8256145
关键字
GFS分布式文件系统
==目标问题 ==
在相对廉价的机器上构建大规模的，可扩展的，高可靠性，分布式文件系统
==核心思想 ==
GFS的设计思想紧密的围绕着它的目标问题，它的几个重要的基本假设是：
- 由于构建系统的是大量的相对廉价的机器，所以硬件的失效是常态，需要有效的容忍各种层级的硬件失效
- 文件的尺寸大于常规文件尺寸，通常以GB为单位
- 文件的批量读写操作比随机读写操作更频繁，而写操作又以添加为主，主要针对这些应用模式进行优化
- 需要支持并发的写操作，对数据的吞吐率的要求高于对低延迟的要求
GFS的基本系统架构和工作模式如下图所示
基本上来说GFS的系统框架可以概括为:
- 单主节点+多数据服务节点
- 主节点维护文件命名空间，权限，数据块映射，储存位置等Meta信息，协调数据服务节点的负载平衡，调度读写操作。所有客户端的读写操作的首次发起，都要通过主节点来获取数据位置信息。
- 为了尽可能减小主节点的负担，客户端后续具体读写数据都是和数据服务节点直接交互，客户端同时Cache部分数据Meta信息，进一步减少主节点负担。
- 主节点将相关Meta信息维护在内存中，以加速检索，用Log/Snapshot/多机备份等多种机制保证Meta数据的可靠性
- 文件划分为固定尺寸的大小(chunk)进行存储，每个Chunk都以多个备份的形式分散存储在不同的数据服务节点上，一方面为了可靠性，另一方面可以增加读数据操作的吞吐率。
- 无论数据服务节点还是客户端代码都不使用Cache缓存数据（不需要），简化系统的复杂性。
==实现 ==
具体的实现还有各种细节需要考量
Chunk Size : GFS默认设置的文件块的尺寸是64MB，较大的文件块尺寸能减少Master节点的管理开销，如更少的Meta数据需要存储，更少的客户端通讯需求等。但较大的文件块尺寸也会带来部分被多个客户端同时读取的文件在某台数据服务节点上造成热点（因为较大的chunk size导致较少的文件块，读取同一个文件可能最终会读取同一个文件块）
Chunk位置信息 :主节点需要将内存中的管理得Meta信息以Log/Snapshot的形式持久化，但是并不持久化文件块的具体位置信息，而是在每次启动时查询数据服务节点，一方面简化了各种灾难恢复情况下，数据一致性的问题。另一方面，数据的存在与否最终根本上还是数据服务节点说了算。
数据交互流程和一致性问题：为了保证不同的数据备份Replica的一致性，就需要保证对所有replica的更新操作的一致性，为了减少主节点的负担，GFS设计了Lease租约来管理Replica，每次操作都会有一个Replica得到具体Chunk的Lease，这个Replica称为Primary，在Lease有效期间，client对数据的更新的控制信息通过该Primary执行和分发，但是数据本身则不一定先写入Primary再分发，而是通过写入离Client最近的节点，再串行化由该节点依次写入临近的节点。这样做是为了最大化网络带宽的利用。
数据完整性：一个Chunk内部数据按64KB划分为一个数据块，对这个数据块进行校验，每个数据服务节点负责校验自己的数据，并且定期扫描所有的文件块，这样有助于及早发现数据的损坏。
空间回收，过期数据检测等：对于删除的文件数据，GFS并不会实时删除其数据块对应的物理文件，而是重命名并标识起来，定期批量回收，这样一方面减少了状态同步的复杂性，另一方面批量处理也有助于性能的提高。对于各种灾难恢复场合下，数据更新可能在某些节点上步调不一致的情况，GFS对每个Chunk都维护了一个版本信息，每次更新操作都会增加对应Chunk的版本号，这个版本号被用在各种读写操作中，以检测数据的合法性。
==相关研究，项目等 ==
HDFS是GFS设计思想的一个开源实现