google file system

网上有不少很好的翻译，本篇文章不再逐字逐句翻译，简单整理一下文章的内容。

都说经典的文章的，过段时日回头看看，会有不一样的感受。先留个坑吧。

1.基本交互流程

gfs是如何的运行的，和客户端的交互流程如上。具体的各个环节如下：

1）client根据需要读取或者写入的文件，offset向master发起请求，请求从master获取相关信息，如持有租约的数据集，以及数据集的位置。如果暂时没有数据集获得租约，master就进行授权，确定一个持有租约数据集。

对于一个chunk，gfs上保存有多份的副本。所谓租约，相当于一个主节点的凭证。是指在对一个chunk进行修改的时候，需要通过master授予租约的方式确定主节点，由主节点维护写入顺序，来保证chunk在各个副本的一致性。

2）master返回数据集位置信息。客户端缓存这些信息。当数据集不可访问，或者主replica不再持有租约的时候，才会再次和master发生交互。

chunk的位置的信息保存在master的内存当中。每次启动的时候会初始化一次，后续通过与chunkserver的心跳来维护chunk的信息，由chunkserver上报chunk的信息。

3）client将数据传输到所有的数据集所在的chunkserver上，按就近的方式传输数据。chunkserver用LRU buffer来缓存数据，直到数据已经得到利用或者过期。

先传输数据，之后再进行写入操作。同时数据传输的方式是链式传输，由一台服务器传输给另外一台最近的服务器。

4）所有的chuckserver都获取到数据之后，client对主chunkserver发起写入请求。主chunkserver通过一个连续的编号确定修改一个修改序列。

5）主数据集所在chunkserver将这样的执行顺序，发送给其他的chunkserver，其他的chunkserver以同样的顺序执行操作。

6）其他chunkserver响应主数据集所在chunkserver请求，以表示已经完成相应操作。

7）主chunkserver回复客户端。如果客户端收到了错误返回，会通过重试的方式来处理。

2.master的职能

1）元数据维护
master内存中维护了文件和chunk的文件路径(namespace)，文件到chunk的映射，chunk各数据集的位置信息。前两种信息通过日志来持久化到本地，也会复制到远程机器作为备份。

2）namespace的锁粒度
文件是通过文件系统的树状结构来组织的，每次对namespace进行修改，会获取文件父目录路径每一层的读锁，以及所需要的修改文件的写锁。

3）数据集分布
提供基于机架级别的数据集隔离。

• 这应该算不上是gfs的特征？应该类似一种配置性的策略？

数据集会倾向于放置到利用率低于平均水平的chunkserver，同时尽量保证chunkserver的“最近创建数据集数”不会太高。其实就是在分布数据集时候考虑负载均衡。

4）清理策略
惰性删除，会对需要delete的文件标记删除，经过一定的期限之后进行删除。

定期对chunk namespace扫描，对于master识别的孤立的chunk，即不可达的chunk，删除内存中对应的元数据。

chunkserver通过心跳上报该chunkserver所拥有的chunk，对于没有在master中记录的chunk，通过心跳的方式回传chunkserver。

5）旧数据集检测

chunk通过版本号来确定是否是最新的。master每次授予租约给chunk，都会递增其版本号，并通知其他的数据集修改。

master定期对chunk的扫描中，对版本号过旧的chunk的数据集标记为不可见。

• 处理方式是标记删除，然后从其他副本中复制？全量复制，或者是能够通过增量复制的方式在旧的数据集上处理？