Google File System 中文版 1.0 版
作者/编著者:阎伟 邮件: andy.yanwei@163.com 博客: http://andyblog.sinaapp.com 微博:http://weibo.com/2152410864 5/33
式保存,Linux 操作系统的文件系统缓存会把经常访问的数据缓存在内存中。
2.4 单一 Master 节点
单一的 Master 节点的策略大大简化了我们的设计。单一的 Master 节点可以通过全局的信息精确定位
Chunk 的位置以及进行复制决策。另外,我们必须减少对 Master 节点的读写,避免 Master 节点成为系统的瓶
颈。客户端并不通过 Master 节点读写文件数据。反之,客户端向 Master 节点询问它应该联系的 Chunk 服务器。
客户端将这些元数据信息缓存一段时间,后续的操作将直接和 Chunk 服务器进行数据读写操作。
我们利用图 1 解释一下一次简单读取的流程。首先,客户端把文件名和程序指定的字节偏移,根据固定
的 Chunk 大小,转换成文件的 Chunk 索引。然后,它把文件名和 Chunk 索引发送给 Master 节点。Master 节
点将相应的 Chunk 标识和副本的位置信息发还给客户端。客户端用文件名和 Chunk 索引作为 key 缓存这些信
息。
之后客户端发送请求到其中的一个副本处,一般会选择最近的。请求信息包含了 Chunk 的标识和字节范
围。在对这个 Chunk 的后续读取操作中,客户端不必再和 Master 节点通讯了,除非缓存的元数据信息过期或
者文件被重新打开。实际上,客户端通常会在一次请求中查询多个 Chunk 信息,Master 节点的回应也可能包
含了紧跟着这些被请求的 Chunk 后面的 Chunk 的信息。在实际应用中,这些额外的信息在没有任何代价的情
况下,避免了客户端和 Master 节点未来可能会发生的几次通讯。
2.5 Chunk 尺寸
Chunk 的大小是关键的设计参数之一。我们选择了 64MB,这个尺寸远远大于一般文件系统的 Block size。
每个 Chunk 的副本都以普通 Linux 文件的形式保存在 Chunk 服务器上,只有在需要的时候才扩大。惰性空间
分配策略避免了因内部碎片造成的空间浪费,内部碎片或许是对选择这么大的 Chunk 尺寸最具争议一点。
选择较大的 Chunk 尺寸有几个重要的优点。首先,它减少了客户端和 Master 节点通讯的需求,因为只
需要一次和 Mater 节点的通信就可以获取 Chunk 的位置信息,之后就可以对同一个 Chunk 进行多次的读写操
作。这种方式对降低我们的工作负载来说效果显著,因为我们的应用程序通常是连续读写大文件。即使是小
规模的随机读取,采用较大的 Chunk 尺寸也带来明显的好处,客户端可以轻松的缓存一个数 TB 的工作数据
集所有的 Chunk 位置信息。其次,采用较大的 Chunk 尺寸,客户端能够对一个块进行多次操作,这样就可以
通过与 Chunk 服务器保持较长时间的 TCP 连接来减少网络负载。第三,选用较大的 Chunk 尺寸减少了 Master
节点需要保存的元数据的数量。这就允许我们把元数据全部放在内存中,在 2.6.1 节我们会讨论元数据全部放
在内存中带来的额外的好处。
另一方面,即使配合惰性空间分配,采用较大的 Chunk 尺寸也有其缺陷。小文件包含较少的 Chunk,甚
至只有一个 Chunk。当有许多的客户端对同一个小文件进行多次的访问时,存储这些 Chunk 的 Chunk 服务器