这篇博客是我阅读著名的 GFS 论文（The Google File System）所总结的笔记以及自己一些的思考。这篇论文是一篇非常经典的论文，尤其对于想要了解分布式或者刚刚开始研究分布式的人来说，是一篇非常好的读物，它里面提到了许多分布式方向的基本问题，许多分布式的研究都是围绕这些基本问题的。

分布式系统

在了解谷歌文件系统（Google File System）之前，我们必须要了解一下有关分布式系统的一些概念。

Q1：一致性是什么？

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

Q2：如果只有一个应用程序，它对文件系统进行了一次写操作，这个应用程序在这次写操作之后的读操作会观测到什么呢？

它会正常观测到它刚刚写入的数据。

Q3：如果另外多个应用程序执行的读操作呢，它们会观测到什么呢？

对于弱一致性的模型来说，这次读操作有可能会读取到已经过期的数据；

对于强一致性的模型来说，读操作读到的始终是上一次写入操作进行完成之后的数据。

强一致性能保证写入操作，但是它会影响性能（强一致性协议复杂）

Q4：理想化的一致性模型是怎样的？

分布式文件系统通过在多个机器上复制文件来保证可用性，在理想化的一致性模型中，在文件系统中所进行的各种操作都要像是在一台机器上进行的操作。实现理想化一致性模型的难点在于处理高并发问题、如何处理分布式集群中的机器崩溃以及达到网络的高效利用，理想化的一致性模型还会出现裂脑问题（split-brain，如果两个存储着相同文件的机器 A，B同时崩溃，其他的机器并不知道是哪一个先崩溃的，所以就不知道该用 A 恢复 B还是用 B 恢复 A）。总之，使用理想化一致性算法会影响性能，并且它的实现非常复杂（例如：Paxos）

GFS 不是采用的理想化一致性模型，但是它解决了机器崩溃恢复的问题以及能够应对高并发操作同时又能相对高效地利用网络。

GFS 是什么？

GFS（Google File System ）是一个大规模分布式文件系统，具有容错的特性（机器崩溃后的处理），并且具有较高性能，能够响应众多的客户端。

GFS 设计背景

• 经常会有机器崩溃（因为机器众多，难免会有机器崩溃）
• 有些存储的文件比较大
• append 操作更常见（在文件后追加，而不是 overwrite 覆盖）
• 主要包括两种读取 （read）操作：一种是大的顺序读取（单个文件读取几百 KB 甚至是几 MB）；另一种是小的随机读取（在随机位置读取几 KB）
• 需要支持并发（例如，多个客户端同时进行 append 操作）

GFS 所需提供操作

create（文件创建）、delete（文件删除）、open（打开文件）、close（关闭文件）、read（读取文件）、write（写入文件）、record append（追加文件）、snapshot（快照）。

GFS 架构

GFS 的架构由一台 master 服务器和许多台文件服务器（chunkserver）构成，并且有若干客户端（client）与之交互。

GFS 特点概述

• 文件分块（chunks），每块有一个64位标识符（chunk handle），它是在 chunk 被创建时由 master 分配的，每一个 chunk 会有3个备份，分别在不同的机器上。
• Master 存储所有的 metadata，包括命名空间（namespace）、访问控制信息（access control）、文件与 chunk 的映射关系（mapping）以