GFS基本框架

一个GFS集群包含单个master和多个chunkserver。GFS文件以若干个大小为64MB的chunk存储在chunkserver磁盘上。当客户端请求访问该文件时，首先向Master请求相关chunk所在的chunkserver地址和chunk句柄，使用句柄找到（通常是最近的）chunkserver完成数据访问工作。

在GFS的框架中，master需要维护所有文件系统元数据，包括文件和chunk的命名空间、文件到chunk的映射、chunk的位置，而且都保存在内存中。其中前两种还会进行持久化保存，存储在master本地磁盘并且拷贝到远程机器。chunk的位置会在master启动时或者周期性向所有chunkserver获取并更新。此外，master还需要负责chunk租赁管理、孤儿chunk的垃圾回收、chunkserver之间的chunk迁移等工作，具体的下面会详细介绍。

容错机制

Master 的容错机制 ：操作日志 + Checkpoint + ShadowMaster

Master每次更新元数据前都需要先写操作日志（WAL），持久化到本地磁盘并拷贝到多个副本成功后，才启动真正的写操作。

为了避免日志过大而引发启动缓慢问题，Master会定期进行日志回收，原理是将当前内存状态冻结并持久化存储到磁盘上，称为Checkpoint。然后，回收该时刻之前的所有日志。若系统此时重启，只需要将Checkpoint加载入内存后.重放Checkpoint点之后的日志即可在内存中重构最新状态。

设置shadow master，持续地读取某个master副本的操作日志，并重放到自己内存，保持与master一致；在master宕机是可以提供可读访问。

ChunkServer的容错机制：复制多个副本 + checksum

为了确保可靠性，每个chunk在多个chunkserver上创建副本（默认三份）。

每个chunk被分为多个64KB的块，每个块对应一个32位的checksum，保存在内存中。读取块副本时，ChunkServer会将读取的数据与校验和进行比较，如果不匹配就会向客户端返回错误。客户端将向其他副本重试读请求，而master则会尽快从其他副本克隆数据创建新的chunk；当新克隆的副本准备就绪，Master命令发生错误的chunkserver删除异常副本，保证了集群的数据完整性。

一致性问题

所有客户端从任何副本上读到的数据都是相同的(consistency)。

元数据的一致性

元数据只会由master统一进行修改，不涉及分布式，所以只需要使用锁机制隔离各个并发的操作，依次执行保证一致性。

Chunk的强一致性

使用租赁机制维护跨副本的一致性写顺序。首先，master在chunk各副本中选择一个Primary，授予租赁权，负责为chunk的所有写操作制定顺序（串行化），所有副本在实施写操作时都必须遵循此顺序。具体的流程描述如下：

• (1,2)客户端向Master获取持有租赁权的chunkserver及其副本的位置信息；客户端缓存这些数据以便后续的操作。只有在Primary不可用，或者Primary回复信息表明它已不再持有租赁权时，客户端才需要重新跟 Master 节点联系。
• (3)客户端将数据推送给所有副本。任何一个chunkserver收到数据后就立刻推送给最近的未收到数据的chunkserver，最大化每个机器的网络带宽。
• (4)确认各副本的数据就位后，发送写请求到Primary。 如果此时有多个客户端向其发送写请求，Primary会为每个请求分配唯一的递增序号。
• (5,6)Primary将写请求推送到所有Secondary副本，请求中已带有分配的序号。每个Secondary副本都会严格按顺序依次实施写操作。完成后“通知”Primary。
• (7)所有副本都完成后，由Primary回复给客户端。任何副本遭遇的任何错误，都会被传递给客户端，客户端会认为该请求失败，重新尝试步骤3-7，实在不行就重试整个流程。

其它重要的技术点总结

如何避免单一master的性能瓶颈

• 客户端只会询问master自己应该访问哪个chunkserver，且客户端会缓存该信息(以GFS文件名和chunk序号作为key）直至过期，减少对master的访问；
• 客户端通常会在一个与master的请求中顺带多索要些其他chunk的信息，且master也可能将客户端索要的chunk后面紧跟的其他chunk信息主动回复回去，避免未来可能发生的client-master交互。
• chunk大小设置为64MB，在尽可能减少客户端与master交互的同时，允许master在内存中缓存元数据。但是隐患是可能导致热点chunk所在的chunkserver负载过大而瘫痪，可以通过调整它的复制级别解决，多复制几份拷贝分担压力。

垃圾延迟删除机制和孤儿Chunk的回收机制

当一个文件被删除时，master不会立刻回收资源，只是将文件重命名为一个带删除时间戳的名字。在master对文件系统命名空间执行常规扫描时，才删除超过3天的隐藏文件。此时该文件在内存中的元数据才会被清除。

此外，对于孤儿chunk的回收的实现，chunkserver会在与master的心跳消息交换中报告其chunk子集，master会识别出元数据中没有的chunk并回复给chunkserver，由chunkserver执行删除操作。

快照机制

快照机制能够快速地为一个文件或整个目录树创建一个副本，主要通过使用写时拷贝技术实现。具体地说，

• master收到快照请求后会立马撤回相关文件对应的chunk副本上的租赁权。
• 撤回租赁后在内存状态快速复制源文件和源目录树的元数据，并将复制得到的元数据映射到相同的chunk上。
• 在下一次客户端需要写入该chunk©时，会向Master请求租赁权持有者，master检查该chunk的引用计数，如果大于1，会新建chunk句柄C’，然后要求所有包含chunk©的副本的chunkserver都为C’创建一份新副本。
• 创建完成后master才会回复客户端。

旧版本侦测

每当master授予一个新的租赁给某个chunk，都会增长chunk版本号并通知各副本。如果某个副本当前不可用，它的chunk版本号不会被更新。chunkserver向master汇报时master能够检测到旧副本的存在，旧副本会在垃圾回收的时候被删除。

chunk副本被创建的三种情况

chunk创建、restore(chunk的副本数量未达到复制级别，需要补充新副本)、重(chong)负载均衡(对必要的副本进行迁移来达到更均衡的磁盘利用率和负载，如新加入chunkserver时)。

Master的多个操作如何避免冲突

如快照和创建新文件。使用命名空间的区域锁机制。命名空间可以理解为是完整的路径名到元数据的映射查找表。每个操作都会为其涉及的节点申请读锁或着写锁，如果两个操作发生锁冲突就会串行执行。为了避免死锁发生，操作必须按特定的顺序申请锁：首先按照命名空间树的层级排序，在相同层级再按字典序。

HDFS VS GFS

简单的说，HDFS是以GFS为基础的工程实现，主要有三方面的区别：

• 【写入模型】GFS 允许同一时刻多个客户端并发写入或追加同一文件；HDFS同一个文件同一个时刻只允许一个客户端写入或追加。相应的，HDFS不需要使用租赁机制来控制并发写操作的执行顺序。
• 【快照】HDFS不支持快照功能，只是运用最基础的复制。
• 【垃圾回收】GFS采用惰性回收策略，而HDFS采用的是直接删除的方式。惰性回收提供应用程序错误操作的回滚机会，且资源的回收在Master空闲时完成，能提升GFS的性能。但延迟回收可能会占用很大的存储空间。