GFS论文总结（上）

前言

半年多假期的的日子马上就要结束了，马上要返校干活了。趁这个周末把GFS论文总结了，回校之后可能就没太多时间了。

整个论文的知识框图如下所示，下面也基本按照这个流程进行总结。

一、Overview

1.1 设计背景（假设）

gfs的提出是建立在一些假设之上的，这些假设基本如下

• 经常会有机器崩溃（因为机器众多，难免会有机器崩溃）
• 存储的文件比较大
• 用户的读取操作更多的是顺序读取而不是随机读取
• 用户的写入操作更多的是追加（append）而不是随机覆盖（overwrite）
• 需要支持并发操作
• 高持续带宽比低延迟更重要（High sustained bandwidth is more important than low latency）（这一点，我也不是很理解）

note::所谓假设，就是某种程度上对系统的抽象。一般来说，各种设计工作都需要对其应用场合做一定程度的假设（抽象）。就我目前的认识来看，工程系统的假设应尽量贴合实际情况，虽然这可能使系统设计工作更复杂。

1.2 架构

整个gfs的架构如上图所示。

一个gfs系统由一个maser结点和多个chunkserver结点构成。其中mater结点相当于中心化的调度结点，其不负责具体的读写操作（master结点上面也没有具体的数据） chunkserver是具体的数据存储和数据传输结点，它负责具体的与client进行数据传输。
下面介绍的读写操作对上图介绍的更详细。

1.3 读操作

Client的读取操作流程如下：

 1. client 将应用程序请求的文件名、大小转化为 chunk index，然后将文件名和 index 发送给 master
 2. master 返回文件的 chunk handle 和所有该文件备份的位置
 3. client 将这两个 master 发送给它的信息缓存起来作为 value，文件名和 chunk index 作为 key
 4. client 向三个备份之一的 chunkserver 发送读请求（选择最近的机器），请求中包含 chunk index 和它要读取的文件的 Byte 范围
 5. chunkserver接受到请求之后，将相应的数据发送给client。

Note:
(1)、如果 client 缓存的信息没有过期,client 就不用在与 master 进行通信了，以后可以直接与 chunkserver 进行通信.
(2)、client请求数据时可以向含有replication的任何一个chunkserver进行请求，这也是其可以获得一定扩展能力（Scalability）的基础。

1.4 写操作

普通写流程主要如上图所示。

 1. client 向 master 请求持有 lease 的 chunk（primary replica）位置和其他 replicas 的位置（如果没有 chunk 持有 lease，那么 master 会授予其中一个 replica 一个 lease）
 2. master 返回 primary 的信息和其他 replicas 的位置，然后 client 将这些信息缓存起来（只有当 primary 无法通信或者该 primary replica 没有 lease 了，client 才会向 master 再次请求）
 3. client 会将数据发送到所有的 replicas，每个 chunkserver 会把数据存在 LRU 缓存中
 4. 在所有的 replicas 都收到了数据之后，client 会向 primary 发送写请求。primary 会给它所收到的所有 mutation 分配序列号（这些 mutation 有可能不是来自于同一个client），它会在自己的机器上按序列号进行操作
 5. primary 给 secondaries 发送写请求，secondaries 会按相同的序列执行操作
 6. secondaries 告知 primary 操作执行完毕
 7. primary 向 client 应答，期间的错误也会发送给 client，client 错误处理程序（error handler）会重试失败的 mutation

note：所谓正常写是和下面所说的append 操作相区别的。正常写操作不能保证强一致性。从某种程度上来说，只能保证最终一致性。

append 流程和上面的有些差不多，但因为数据时追加操作，往副本的末尾进行追加，所以其不是幂等的（多次执行相同操作，结果是一样的）。具体如下：

1、Client向Master请求文件的最后一个chunk信息。
2、如果master发现chunk 没有primary（或者lease过期了）
	2a.如果没有chunkservers的版本号是最新的，返回错误
	2b.从那些含有最新版本号的chunkserver中选择primary 和secondaries
	2c.增加版本号，写入日志
	2d.通知primary 和secondaries 新的版本号
	2e.replications 将版本号写入disk
3、Master通知Client primary 和secondaries的位置信息
4、Client将数据传到 各个replications中
5、Client通知Primary写入
6、Primary检测其lease未过期，而且chunk还有剩余空间
7、Primary选择offset，这里是在chunk的末尾
8、Primary将数据写入对应的位置
9、Primary 通知每个secondaries 选择的offset，并让其写入
10、Primary等待所有的secondaries的reply 或者超时
11、返回Client结果
12、如果Client收到error的话，重试

note: 这个append和正常写操作本质上是一样的，但是因为其写入的位置不同，因此可能会造成数据的不一致性的不同。在Consistency 中会说明。

二、Master Opration

GFS 为了简化设计，在整个系统中只有一个 master 进行管理(single master)。其主要有以下职责：

2.1 命名空间管理和锁机制

对于Master来说，其主要保存两张表：

（1）、文件名到 chunk 句柄的映射：filename --> array of chunk handles（n）
（2）、chunk 句柄到 chunk元信息的映射（包括副本位置，chunk 版本号，主 chunk，租约过期时间）：chunk handle —> list of chunk servers(v)/version(nv)/ Primary(v) / lease expire time(v)

这两个数据结构都存在内存（RAM）中。但为了宕机恢复，需要把一些信息（标记为 nv：non-volatile）写到硬盘上，即：
（1）、读取，从内存中读即可。
（2）、写入，修改内存同时在磁盘上记操作日志（ LOG）+ 快照（CheckPoint）。
对于另外一些信息（标记为v：volatile），根据从 chunkserver 来的心跳构建即可。

关于这个锁机制，我没怎么认真看，详细的可以参考这篇博客

2.2 Repica的存储、创建、以及均衡

同样，这一部分，并没有什么比较新奇的观点，不重复造轮子了。参考这篇博客

note：关于这一部分的内容，主要是为了提高系统的资源利用率和容错性，gfs在存储chunk的时候会做出一些抉择，如优先选用磁盘空间较为充足的进行存储等等

2.3 垃圾回收

基本垃圾回收过程如下面这段文字所述：

note：文件的回收机制有点类似算法中的“懒惰删除”，即不真正立即删除，而是打上一个flag,下次遇到这个flag的时候就知道，这个chunk已经是删除的了，这样有利于提高效率和利用率。

2.4 过期 replica 检测

note:lease 机制从某种程度上来说是利用时间的单向性，来进行“通信的”一种手段。（当然，这一般要求时钟的同步）

关于一致性和容错性留在下一篇博客中说明了。