一、设计预期
设计预期往往针对系统的应用场景，是系统在不同选择间做balance的重要依据，对于理解GFS在系统设计时为何做出现有的决策至关重要。所以我们应重点关注：
- 失效是常态
- 主要针对大文件
- 读操作：大规模流式读取、小规模随机读取
- 写操作：大规模顺序追加写，写入后很少修改
- 高效明确定义的并行追加写
- 稳定高效地网络带宽
二、整体设计
1、系统架构
GFS主要由以下三个系统模块组成：
- Master：管理元数据、整体协调系统活动
- ChunkServer：存储维护数据块（Chunk），读写文件数据
- Client：向Master请求元数据，并根据元数据访问对应ChunkServer的Chunk
2、设计要点
1）Chunk尺寸
由于GFS主要面向大文件存储和大规模读写操作，所以其选择了远大于一般文件系统的64MB的Chunk尺寸。
好处：
- 减少元数据量，便于客户端预读缓存，减少客户端访问Master的次数，减小Master负载；
- 减少元数据量，Master可以将元数据放在内存中；
- 客户端短时间内工作集落在同一Chunk上的概率更高，减少客户端访问不同ChunkServer建立TCP连接的次数，从而减少网络负载。
坏处：
- 易产生数据碎片；
- 小文件占用Chunk少，对小文件的频繁访问会集中在少数ChunkServer上，从而产生小文件访问热点。
可能的解决方案：
- 增大小文件复制参数；
- 客户端间互传数据。
2）元数据存储方式
Master存储的元数据包括：命名空间、文件和Chunk的对应关系、Chunk位置信息。
命名空间、文件和Chunk的对应关系的存储方式：
- 内存：真实数据；
- 磁盘：定期Checkpoint（压缩B树）和上次CheckPoint后的操作日志；
- 多机备份：Checkpoint文件和操作日志。
Chunk位置信息的存储方式：
- 内存：真实数据
- 磁盘：不持久存储
系统启动和新Chunk服务器加入时从Chunk服务器获取。避免了Master与ChunkServer之间的数据同步，只有Chunk服务器才能最终确定Chunk是否在它的硬盘上。
3）一致性模型
命名空间修改：原子性和正确性
文件数据修改（之后详细解释）：
- 修改失败：不一致
- 串行随机写：一致且已定义
- 并行随机写：非原子写，一致但未定义
- 串行/并行追加写（推荐）：少量不一致，保证已定义
三、详细设计
1、系统交互设计
1）重要原则
最小化所有操作与Master的交互。
2）缓存机制
最小化读取操作与Master的交互：
客户端访问Chunk前从Master获取元数据的过程中，会预取和缓存部分Chunk的元数据，从而减少与Master的交互。
2）租约机制
最小化变更操作与Master的交互：
Master收到变更操作请求后
- 选择一个Chunk副本发放定时租约作为主Chunk并返回给客户端；
- 客户端与主Chunk进行通信进行变更操作；
- 租约超时前，对该Chunk的变更操作都由主Chunk进行序列化控制。
3）数据流与控制流分离
数据推送与控制操作同时进行。
数据流：管道方式按最优化的Chunk服务器链推送，以最大化带宽，最小化延时（全双工交换网络，每台机器进出带宽最大化）；
控制流：
- 主ChunkServer确定二级副本接收完毕后，对所有变更操作分配连续序列号（序号确定操作顺序）；
- 按序修改本地数据；
- 请求二级副本按序修改；
- 所有副本修改完成成功，否则失败重做。
4）非原子写操作
一次写入数据过大，可能被客户端分为多个写操作，这些写操作序号可能不连续，被其他并发写操作打断或覆盖，出现数据一致但未定义的状态。
5）原子记录追加
追加写时GFS推荐的写入方式，应重点研究。
a. 原子记录追加：客户端指定写入数据，GFS返回真实写入偏移量。
b. 追加写的过程：
- 追加操作会使Chunk超过尺寸
- 填充当前Chunk；
- 通知二级副本做同样操作；
- 通知客户机向新Chunk追加；
- 追加操作不会使Chunk超过尺寸
- 主Chunk追加数据；
- 通知二级副本写在相同位置上；
- 成功 - 返回偏移； 失败 - 再次操作。
c. 追加结果：失败的追加操作可能导致Chunk间字节级别不一致，但当最终追加成功后，所有副本在返回的偏移位置一致已定义，之后的追加操作不受影响。如下图所示：
d. 冗余数据处理：对于追加写产生的冗余数据
- Chunk尺寸不足时的填充数据
- 追加失败时产生的重复内容
可在插入数据时附带记录级别的Checksum或唯一标识符，在客户端读取数据时进行校验过滤。
6）快照
使用COW技术，瞬间完成。快照实现的过程：
- 收回文件所有Chunk的租约；
- 操作元数据完成元数据拷贝；
- 客户端要写入该文件的Chunk时，Master通知该Chunk所在ChunkServer进行本地拷贝；
- 发放租约给拷贝Chunk；
- 返回拷贝Chunk的位置信息。
2、Master节点设计
1）名称空间管理
多操作并行，名称空间锁保证执行顺序，文件操作需获得父目录读锁和目标文件/目录写锁。
2）副本位置
Chunk跨机架分布：
好处 -
- 防止整个机架破坏造成数据失效
- 综合利用多机架整合带宽（机架出入带宽可能小于机架上机器的总带宽，所以应最大化每台机架的带宽利用率）；
坏处 - 写操作需跨机架通信。
3）Chunk管理
a. 创建操作，主要考虑：
- 平衡硬盘使用率；
- 限制单ChunkServer短期创建次数（创建开销虽小，但每次创建往往意味着大量的后续写入）；
- 跨机架分布。
b. 重复制，即有效副本不足时，通过复制增加副本数。优先考虑：
- 副本数量和复制因数相差多的；
- live（未被删除）文件的；
- 阻塞客户机处理的
Chunk进行重复制。策略与创建类似。
c. 重负载均衡，通过调整副本位置，平衡格机负载。策略与创建类似。新ChunkServer将被逐渐填满。
4）垃圾回收
惰性回收空间：删除操作仅在文件名后添加隐藏标记，Master在常规扫描中删除超时隐藏文件的元数据，并通知对应ChunkServer删除Chunk。
好处 -
- 与创建失败的无效Chunk一致的处理方式；
- 批量执行开销分散，Master相对空闲时进行；
- 删除操作一定时间内可逆转。
坏处 - 不便于用户进行存储空间调优。
解决方案 - 再次删除加速回收，不同命名空间不同复制回收策略。
5）过期失效副本检测
过期检测：Master维护Chunk级别版本号，新租约增加Chunk版本号，并通知所有副本更新版本号，过期Chunk会因版本号过旧被检测。
3、容错机制设计
1）高可用性
主要的提高可用性的机制：
- 组件快速恢复
- Chunk复制
- Master服务器复制
- Checkpoint和操作日志多机备份；
- Master进程失效重启，硬件失效则新机器重启Master进程；
- “影子”Master，通过操作日志“模仿”主Master操作，元数据版本稍慢。作用 - 分担一定负载、失效期暂时接管。
2）数据完整性
ChunkServer独立维护CheckSum检验副本完整性。原因：
- 跨Chunk服务器比较副本开销大；
- 追加操作造成的的byte级别不一致，导致无法通过比较副本判断完整性。
Chunk读取和Chunk服务器空闲时，进行CheckSum校验，发现损坏Chunk上报Master，进行重复制。
Checksum校验的开销：
- Checksum读取开销；
- Checksum校验计算开销。
但整体开销可以接受，特别是对追加写操作。
覆盖写与追加写的Checksum计算开销比较。两者的关键区别在于不完整块的CheckSum计算：
- 追加写 - 对最后一个不完整块，在写入后进行增量的CheckSum计算。New CheckSum由Old CheckSum和新数据算出，未对原有数据重新计算，原有数据损坏，依然可以发现；
- 覆盖写 - 对第一个和最后一个不完整块，在写之前进行CheckSum校验。否则，覆盖写只能重新对整块计算CheckSum，若写操作未覆盖部分存在损坏数据，新CheckSum将从包含损坏数据的Chunk算出，之后再也无法校验出该损坏数据。
四、总结
本文是我在阅读论文《The Google File System》时记下的笔记，对论文的各部分内容进行了梳理。
系统设计过程往往就是在各种因素间根据目标需求权衡利弊的过程。分布式系统设计需要权衡的问题存在许多共性，GFS在设计过程中基于分布式环境的特点，做的许多重要决策对于其他分布式系统开发具有指导性的意义。
所以，我尽力把觉得有趣的设计要点进行了提炼，并对重要细节进行了重点分析，特别是各种权衡带来的好处和坏处，以及针对最终选择带来的坏处的弥补方案。
如果这篇文章在梳理自己思路的同时，能为感兴趣的朋友们提供一点点帮助，那也算做了件有意义的事情了！