Google的三大核心关键技术GFS.docVIP

谷歌文件系统?GFS是一个可扩展分布式文件系统，用于大型、分布式、对大量数据进行访问应用。它运行于廉价一般硬件上，但能够提供容错功效。它能够给大量用户提供总体性能较高服务。?1、设计概览?（1）设计想定?GFS和过去分布式文件系统有很多相同目标，但GFS设计受到了目前及预期应用方面工作量及技术环境驱动，这反应了它和早期文件系统显著不一样设想。这就需要对传统选择进行重新检验并进行完全不一样设计见解探索。?GFS和以往文件系统不一样见解以下：?1、部件错误不再被看成异常，而是将其作为常见情况加以处理。因为文件系统由成百上千个用于存放机器组成，而这些机器是由廉价一般部件组成并被大量用户机访问。部件数量和质量使得部分机器随时全部有可能无法工作而且有一部分还可能无法恢复。所以实时地监控、错误检测、容错、自动恢复对系统来说必不可少。?2、根据传统标准，文件全部很大。长度达多个GB文件是很日常。每个文件通常包含很多应用对象。当常常要处理快速增加、包含数以万计对象、长度达TB数据集时，我们极难管理成千上万KB规模文件块，即使底层文件系统提供支持。所以，设计中操作参数、块大小必需要重新考虑。对大型文件管理一定要能做到高效，对小型文件也必需支持，但无须优化。?3、大部分文件更新是经过添加新数据完成，而不是改变已存在数据。在一个文件中随机操作在实践中几乎不存在。一旦写完，文件就只可读，很多数据全部有这些特征。部分数据可能组成一个大仓库以供数据分析程序扫描。有些是运行中程序连续产生数据流。有些是档案性质数据，有些是在某个机器上产生、在另外一个机器上处理中间数据。因为这些对大型文件访问方法，添加操作成为性能优化和原子性确保焦点。而在用户机中缓存数据块则失去了吸引力。?4、工作量关键由两种读操作组成：对大量数据流方法读操作和对少许数据随机方法读操作。在前一个读操作中，可能要读几百KB，通常达 1MB和更多。来自同一个用户连续操作通常会读文件一个连续区域。随机读操作通常在一个随机偏移处读多个KB。性能敏感应用程序通常将对少许数据读操作进行分类并进行批处理以使得读操作稳定地向前推进，而不要让它来往返回读。?5、工作量还包含很多对大量数据进行、连续、向文件添加数据写操作。所写数据规模和读相同。一旦写完，文件极少改动。在随机位置对少许数据写操作也支持，但无须很高效。?6、系统必需高效地实现定义完好大量用户同时向同一个文件添加操作语义。?（2）系统接口?GFS提供了一个相同地文件系统界面，即使它没有向POSIX那样实现标准API。文件在目录中按层次组织起来并由路径名标识。?（3）体系结构：?一个GFS集群由一个master和大量chunkserver组成，并被很多用户（Client）访问。图1所表示。Master和 chunkserver通常是运行用户层服务进程Linux机器。只要资源和可靠性许可，chunkserver和client能够运行在同一个机器上。?文件被分成固定大小块。每个块由一个不变、全局唯一64位chunk－handle标识，chunk－handle是在块创建时由 master分配。ChunkServer将块看成Linux文件存放在当地磁盘并能够读和写由chunk－handle和位区间指定数据。出于可靠性考虑，每一个块被复制到多个chunkserver上。默认情况下，保留3个副本，但这能够由用户指定。?Master维护文件系统所以元数据（metadata），包含名字空间、访问控制信息、从文件到块映射和块目前位置。它也控制系统范围活动，如块租约（lease）管理，孤儿块垃圾搜集，chunkserver间块迁移。Master定时经过HeartBeat消息和每一个 chunkserver通信，给chunkserver传输指令并搜集它状态。?和每个应用相联GFS用户代码实现了文件系统API并和master和chunkserver通信以代表应用程序读和写数据。用户和master交换只限于对元数据（metadata）操作，全部数据方面通信全部直接和chunkserver联络。?用户和chunkserver全部不缓存文件数据。因为用户缓存益处微乎其微，这是因为数据太多或工作集太大而无法缓存。不缓存数据简化了用户程序和整个系统，因为无须考虑缓存一致性问题。但用户缓存元数据（metadata）。Chunkserver也无须缓存文件，因为块时作为当地文件存放。?（4）单master。?只有一个master也极大简化了设计并使得master能够依据全局情况作出优异块放置和复制决定。不过我们必需要将master对读和写参与减至最少，这么它才不会成为系统瓶颈。Client历来不会从master读和写文件数据。Client只是问询ma