哈巴狗

摘要
GFS：google file system，谷歌的分布式文件系统，运行在廉价的PC上，但仍能提供高可靠，高性能的服务。

1.简介
设计目标：
（1）高性能（performance）；
（2）可扩展（scalability）；
（3）高可靠性（reliability）；
（4）高可用（availability）；

假设与设计思路：
（1）组件失效是常态（component normal failures），因此持续监控、错误检测、灾难冗余、自动恢复机制必须具备；
（2）大文件是常态（GB files common），因此IO操作，block size都需要重新考虑；
（3）追加写设计（data appending），几乎没有随机写，这样考虑的原因是基于性能优化与操作原子性；
（4）提供API以简化应用程序，例如提供原子性写，而无需应用程序来同步互斥以保证数据一致性；

2.设计概览
2.1设计预期
（1）假设与设计思路中的第一点；
（2）假设与设计思路中的第二点；
（3）应用工作负载有两种读取模式：大量流式顺序读，少量随机读；
（4）应用工作负载写入模式：大量顺序追加写入；
（5）系统必须明确定义多客户端并发追加写的行为；
（6）高速、高性能并行远比低延时重要（意味着吞吐量比响应速度更重要）；

2.2接口
支持文件，文件以分层目录形式组织，用路径名称来标识。
（1）支持传统常用文件操作：创建、删除、打开、关闭、读、写；
（2）支持快照（snapshot）：低成本创建文件或目录树的拷贝；
（3）支持记录追加（record append）：允许多个客户端同时对一个文件进行数据追加，且保证追加操作的原子性；

2.3架构
（1）一个GFS集群由单master，多chunkserver，多client组成；
（2）文件被切分为多个固定大小（fixed-size）的chunk，每个chunk有一个64bit的唯一标识（handle），每个chunk在多个chunkserver上保存有多副本（默认为3份）；
（3）master维护元数据（metadata），元数据包括名字空间（namespace），访问控制信息（acl），文件到chunk的映射（mapping from file to chunk）,chunk的位置信息（location of chunks）；master还负责chunk的lease管理，孤儿chunk的回收，chunk的自动迁移；master定期向chunkserver发送心跳，维护其状态信息；
（4）client的API以库的形式提供；
（5）client和chunkserver都不缓存文件数据（数据太大了），但会缓存元数据，如chunkserver的信息；

图一：GFS架构

2.4单master策略
此处的单master指逻辑上的master单点。
（1）单master的设计极大的简化了设计；它具有全局视野，可以轻易实施chunk定位与迁移，复制策略。为了避免单master成为系统的瓶颈，必须减少client对master的读写：client向master询问它应该访问的chunkserver，并缓存chunkserver信息，后续都只会通过chunkserver读写数据；
（2）简单解释下读写流程：
首先，客户端把文件名与字节偏移，计算出chunk索引；
然后，将chunk索引发送置master，master将返回chunk表示与副本的位置信息；此时客户端会缓存这些信息；
之后，客户端发送请求至其中一个副本（一般选最近的），请求包含chunk的标识与读写字节范围；之后就不需要再与master交互了（除非过期）；

2.5chunk大小
GFS的chunk大小选择为64M，优点如下：
（1）大chunk存储容量大，减少客户端与master的交互；
（2）大chunk存储容量大，尽量使一次写操作只与一个chunkserver交互，保持tcp连接，减少网络负载；
（3）减少master中元数据的存储量（全部保存至内存）；
缺点如下：
（1）小文件往往只存储在一个chunk中，使存储这些chunk的chunkserver容易成为热点；
解决办法：
（1）对于读热点，增加冗余份数；
（2）应用层可以增加如“从其他客户端读取数据”等类似策略；

2.6元数据
master存储3种主要元数据，且都放在内存中：
（1）文件和chunk的名字空间；
（2）文件和chunk的对应关系；
（3）每个chunk副本的位置。
前两种元数据的任何变更同时也会记录到日志中（当然刷到磁盘上），日志会进行冗余复制。
原因：
（1）master挂掉不会导致数据不一致；
（2）chunk副本位置不记录日志，master启动、有chunkserver加入时，会向各个chunkserver轮询其存储的chunk信息。

2.6.1内存中的数据结构
潜在问题：
（1）元数据放在内存中，内存是否够用：64字节的struct管理64MB的chunk信息，不是问题；
（2）名字空间使用前缀压缩算法压缩，也在64字节以下；

2.6.2chunk位置信息
（1）定时向各个chunkserver轮询chunk位置信息；
（2）轮询避免了chunkserver加入、离开、更名、失效、重启时出现的数据不一致情况；

2.6.3日志
日志记录元数据的历史变更记录，它是元数据唯一的持久化存储，同时它还保存操作时间线；
chunk、文件连同它们的版本，都由它们创建的时间永久标识；
日志写成功后，才会响应客户端；
日志必须足够小；
容灾恢复需要最近一次checkpoint以及其后的日志；

2.7一致性模型
2.7.1机制
（1）名字空间的修改是原子性的，它们由master节点控制；
（2）master节点的日志保证了元数据操作的顺序性；
（3）读写顺序可能引发的不一致：

2.7.2实现
（1）只追加写，不覆盖写；
（2）checkpoint，checkpoint包含程序级别的校验和；
（3）写操作自验证；
（4）记录自标识；