谷歌三大论文之一-Google File System读书笔记_google file system问题

1.GFS主要需要关注的几个问题是什么？

（1）系统由许多廉价的普通组件组成，组件失效是一种常态。系统必须持续监控自身的状态，它必须将组件失效作为一种常态，能够迅速地侦测、冗余并恢复失效的组件

（2）系统存储一定数量的大文件，以通常的标准衡量，我们的文件非常巨大，采用管理数亿个KB大小的小文件的方式非常不明智，因此，设计的假设条件和参数，比如I/O操作和Block的尺寸都需要重新考虑

（3）我们定义绝大部分的文件修改是采用在文件尾部追加数据，而不是覆盖原来的数据。系统的主要工作负载由两种操作组成：大规模的流式存储和小规模的随机存储，当然还包括大规模的、顺序的、数据追加的写操作。所以，我们还要解决一个问题，就是系统必须高效的、行为定义明确实现多客户端并行追加数据到同一个文件（ps：我们还需要给出使用最小的同步开销来实现的原子的多路追加数据操作）

（4）需要提供一套类似传统文件的API接口函数，文件以分层目录的形式组织，用路径名来标识，并需要提供快照和记录追加操作

2.架构设计

首先我们要明确几点：

GFS将整个系统的节点分为三类角色：Client（客户端）、Master（主服务器）和Chunk Server（数据块服务器）。

client（客户端）：Client是GFS提供给应用程序的访问接口，它是一组专用接口，不遵守POSIX规范，以库文件的形式提供。应用程序直接调用这些库函数，并与该库链接在一起。该客户端代码主要实现了GFS文件系统的API接口函数、应用程序与Master节点和Chunk服务器的通讯。注意：客户端和Master节点之间通信只获取元数据，所有的数据操作都是由客户端直接和Chunk服务器交互的。

Master（主服务器）：Master是GFS的管理节点，在逻辑上只有一个，它保存系统的元数据，负责整个文件系统的管理，是GFS文件系统中的“大脑”。具体元数据信息包括名字空间、访问控制信息、文件和chunk的映射信息、以及当前chunk的位置信息等。具体操作管理有：chunk的租用管理、孤儿chunk的回收、以及chunk在chunk服务器之间的迁移。

Chunk Server（数据块服务器）:Chunk Server负责具体的存储工作。数据以文件的形式存储在Chunk Server上，Chunk Server的个数可以有多个，它的数目直接决定了GFS的规模。GFS将文件按照固定大小进行分块，默认是64MB，每一块称为一个Chunk（数据块），每个Chunk都有一个对应的索引号（Index）。

此种架构设计的特点:

1.GFS实现了控制流和数据流的分离。Client和Master之间只有控制流，没有数据流，极大地降低了Master的负载。Client和Chunk Server之间直接传输数据流，同时由于文件被分为多个Chunk进行分布式存储，Client可以同时访问多个Chunk Server，从而使整个系统的IO高度并行，整体性能得到提高

2.采用中心服务器模式

（1）可以方便的操作Chunk Server（增删改查）

（2）Master可以掌握系统内所有Chunk Server的情况，方便进行负载均衡

（3）不存在元数据的一致性问题（因为只有一个中心server，所以云数据也只有一份），当然，此处只是相对而言，我们说的单一master节点的含义是GFS系统中只存在一个逻辑上的Master组件。实际一个逻辑上的Master节点默认包括两台物理机

3.无论是客户端还是Chunk服务器都不需要缓存文件数据

             （1）文件操作大部分是流式读写，不存在大量重复的读写，因此即使使用cache对系统性能的提高也不大

　　　 （2）Chunk Server上的数据存储在本地文件系统上（Linux File System），若真的出现频繁存取，那么本地文件系统的cache也可以支持

　　　 （3）若建立系统cache，那么cache中的数据与Chunk Server中的数据的一致性很难保证

             （4）注意是不缓存文件数据，客户端还是会缓存一些查找到的元数据信息

4.Chunk尺寸选的较大

GFS选择64MB

        优点：

             （1）只需要少量和Master节点的通信就可以获取Chunk的位置信息，之后就可以多次进行读写操作

             （2）选用较大的Chunk尺寸减少了Master节点需要保存的元数据的数量。这就允许我们把元数据全部放到内存中

       缺点：

             （1）因内存碎片造成空间浪费

             （2）造成热点问题

元数据的设计：

 Master服务器存储3种类型的元数据

Chunk位置信息

注意：Master服务器并不持久化保存哪个chunk服务器存有指定Chunk的副本的信息。Master服务器只是在启动的时候轮询Chunk服务器以获取这些信息。Master服务器能够保证它持有的信息始终是最新的，因为它控制了所有的Chunk位置的分配，而且通过周期性的心跳信息监控Chunk服务器的状态。

操作日志

操作日志是干嘛的？保存了关键的元数据变更历史记录。有两点我们需要注意，第一：操作日志是元数据唯一的持久化存储记录。第二：作为判断同步操作顺序的逻辑时间（通过逻辑日志序号作为操作发生的逻辑时间）

Master服务器在灾难恢复时，通过重演操作日志把文件系统恢复到最近的状态。Master服务器在日志增长到一定量时对系统状态做一次快照（CheckPoint）。CheckPoint文件以压缩B-树数据结构存储，可以直接映射到内存。重点：Master服务器使用独立的线程切换到新的日志文件和创建新的checkpoint文件。

一致性模型

  1.命名空间锁提供了原子性和正确性的保障

  2.Master节点的操作日志定义了这些操作在全局的顺序

 什么是一致性？

在分布式文件系统中，很重要的一部分就是数据的复制（replica），为了保证分布式文件系统的高可用性，我们常常会把文件在不同的机器上存储多份，一致性的要求就是保证这些不同机器上的复制品（replicas）能够保持一致。

什么是未定义？

如果对文件的数据修改之后，region是一致的，并且客户端能够理解写入操作的全部内容，那么region是“已定义的”，反之，什么是未定义的呢？举例说明：write中，并行写可能造成数据交叉，那么对于客户端来说，不同客户端读到的数据是一致的，但是读出来的内容是一种未定义的状态

数据修改操作分为写入和记录追加两种。

重点：GFS如何确保被修改的文件region是已定义的？？

（a）对Chunk的所有副本的修改操作顺序一致

（b）使用Chunk的版本号来检测副本是否因为它所在的Chunk服务器宕机而错过修改操作而导致其失效。失效的副本不会进行任何修改操作，master服务器也不再返回Chunk副本信息，会被垃圾收集系统尽快回收

我们需要关注的几点

1. GFS 通过在所有的备份（replicas）上应用顺序相同的操作来保证一个文件区域的 defined（具体细节后面会讨论，采用lease机制）
2. GFS 会使用 chunk version（版本号）来检测 replicas 是否过期，过期的 replicas 既不会被读取也不会被写入
3. GFS 通过握手（handshakes）来检测已经宕机的 chunkserver
4. GFS 会通过校验和（checksuming）来检测文件的完整性

数据流

数据沿着一个chunk服务器链顺序推送，而不是以其他拓扑形式分散推送。

原子的记录追加

GFS保证至少有一次原子的写入操作成功执行，类似以O_APPEND模式打开的文件，多个并发写操作在没有竞争条件的行为。

Master节点的操作

（1）管理所有的名称空间操作

（2）管理所有chunk的相关操作（包括决定chunk的存储位置，创建新chunk和它的副本）

（3）在所有的chunk服务器之间进行负载均衡

（4）回收机制

名称空间管理：

GFS的名称空间是一个全路径和元数据映射关系的查找表

在存储名称空间的树形结构上，每个节点（绝对路径的文件名或绝对路径的目录名）都有一个关联的读写锁

每个Ｍａｓｔｅｒ节点的操作在开始之前都要获得一系列的锁

待续