失效链接处理 |
Google-File-System中文版_1.0 PDF 下载
本站整理下载:
相关截图:
主要内容:
2 设计概述
2.1 设计预期
在设计满足我们需求的文件系统时候,我们的设计目标既有机会、又有挑战。之前我们已经提到了一些
需要关注的关键点,这里我们将设计的预期目标的细节展开讨论。
系统由许多廉价的普通组件组成,组件失效是一种常态。系统必须持续监控自身的状态,它必须将组件
失效作为一种常态,能够迅速地侦测、冗余并恢复失效的组件。
系统存储一定数量的大文件。我们预期会有几百万文件,文件的大小通常在 100MB 或者以上。数个 GB
大小的文件也是普遍存在,并且要能够被有效的管理。系统也必须支持小文件,但是不需要针对小文件做专
门的优化。
Google File System 中文版 1.0 版
作者/编著者:阎伟 邮件: andy.yanwei@163.com 博客: http://andyblog.sinaapp.com 微博:http://weibo.com/2152410864 3/33
系统的工作负载主要由两种读操作组成:大规模的流式读取和小规模的随机读取。大规模的流式读取通
常一次读取数百 KB 的数据,更常见的是一次读取 1MB 甚至更多的数据。来自同一个客户机的连续操作通常
是读取同一个文件中连续的一个区域。小规模的随机读取通常是在文件某个随机的位置读取几个 KB 数据。
如果应用程序对性能非常关注,通常的做法是把小规模的随机读取操作合并并排序,之后按顺序批量读取,
这样就避免了在文件中前后来回的移动读取位置。
系统的工作负载还包括许多大规模的、顺序的、数据追加方式的写操作。一般情况下,每次写入的数据
的大小和大规模读类似。数据一旦被写入后,文件就很少会被修改了。系统支持小规模的随机位置写入操作,
但是可能效率不彰。
系统必须高效的、行为定义明确的2实现多客户端并行追加数据到同一个文件里的语意。我们的文件通常
被用于“生产者-消费者”队列,或者其它多路文件合并操作。通常会有数百个生产者,每个生产者进程运行
在一台机器上,同时对一个文件进行追加操作。使用最小的同步开销来实现的原子的多路追加数据操作是必
不可少的。文件可以在稍后读取,或者是消费者在追加的操作的同时读取文件。
高性能的稳定网络带宽远比低延迟重要。我们的目标程序绝大部分要求能够高速率的、大批量的处理数
据,极少有程序对单一的读写操作有严格的响应时间要求。
2.2 接口
GFS 提供了一套类似传统文件系统的 API 接口函数,虽然并不是严格按照 POSIX 等标准 API 的形式实现
的。文件以分层目录的形式组织,用路径名来标识。我们支持常用的操作,如创建新文件、删除文件、打开
文件、关闭文件、读和写文件。
另外,GFS 提供了快照和记录追加操作。快照以很低的成本创建一个文件或者目录树的拷贝。记录追加
操作允许多个客户端同时对一个文件进行数据追加操作,同时保证每个客户端的追加操作都是原子性的。这
对于实现多路结果合并,以及“生产者-消费者”队列非常有用,多个客户端可以在不需要额外的同步锁定的
情况下,同时对一个文件追加数据。我们发现这些类型的文件对于构建大型分布应用是非常重要的。快照和
记录追加操作将在 3.4 和 3.3 节分别讨论。
|