> For the complete documentation index, see [llms.txt](https://mit-public-courses-cn-translatio.gitbook.io/mit6-824/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mit-public-courses-cn-translatio.gitbook.io/mit6-824/lecture-03-gfs/3.3-gfs-te-dian.md).

# 3.3 GFS的设计目标

让我们来讨论GFS吧。GFS做了很多工作来解决前面提到的问题，虽然不够完美，但是GFS已经做的很好了。

GFS在2003年提出，距今已经有很长一段时间了。实际上，在当时，互联网的规模已经很大了，人们也在构建大型网站，在那之前，人们也对分布式系统做了数十年的研究。所以，在当时，至少在学术领域，人们知道如何构建高度并行且具备容错的分布式系统。不过在当时，很少有在工业界能有应用这些学术界思想的例子。大概从GFS论文发表的时间起，像Google这样的大型网站开始构建严格意义上的分布式系统。这让像我（Robert教授）这样的学术界分子感到非常兴奋，因为终于看到像Google这样的拥有大量数据的公司开始实际使用分布式系统。Google拥有远超过单个磁盘容量的数据，例如从整个互联网爬出来的网页，YouTube视频，用来构建搜索索引的中间文件，Web服务器中的大量日志文件等。所以，Google有大量的数据，需要大量的磁盘来存储这些数据，并且需要能借助MapReduce这样的工具来快速处理这些数据。所以，Google需要能够快速的并行访问这些海量数据。

Google的目标是构建一个大型的，快速的文件系统。并且这个文件系统是全局有效的，这样各种不同的应用程序都可以从中读取数据。一种构建大型存储系统的方法是针对某个特定的应用程序构建特定的裁剪的存储系统。但是如果另一个应用程序也想要一个大型存储系统，那么又需要重新构建一个存储系统。如果有一个全局通用的存储系统，那就意味着如果我存储了大量从互联网抓取的数据，你也可以通过申请权限来查看这些数据，因为我们都使用了同一个存储系统。这样，任何在Google内部的人员都可以根据名字读取这个文件系统（GFS）中可被共享的内容。

![](/files/-MDXI_VxoZSqDF04_aPC)

为了获得大容量和高速的特性，每个包含了数据的文件会被GFS自动的分割并存放在多个服务器之上，这样读写操作自然就会变得很快。因为可以从多个服务器上同时读取同一个文件，进而获得更高的聚合吞吐量。将文件分割存储还可以在存储系统中保存比单个磁盘还要大的文件。

![](/files/-MDXKvO9pGrGUnZEdAnz)

因为我们现在在数百台服务器之上构建存储系统，我们希望有自动的故障修复。我们不希望每次服务器出了故障，派人到机房去修复服务器或者迁移数据。我们希望系统能自动修复自己。

![](/files/-MDXL-X0ENTvDi2hXQ-6)

还有一些特征并非是设计目标。比如GFS被设计成只在一个数据中心运行，所以这里并没有将副本保存在世界各地，单个GFS只存在于单个数据中心的单个机房里。理论上来说，数据的多个副本应该彼此之间隔的远一些，但是实现起来挺难的，所以GFS局限在一个数据中心内。

![](/files/-MDXM8VamCWMPY3889XI)

其次，GFS并不面向普通的用户，这是一个Google内部使用的系统，供Google的工程师写应用程序使用。所以Google并没有售卖GFS，它或许售卖了基于GFS的服务，但是GFS并不直接面向普通用户。

![](/files/-MDXMmH0tKKXnFNxwsNW)

第三，GFS在各个方面对大型的顺序文件读写做了定制。在存储系统中有一个完全不同的领域，这个领域只对小份数据进行优化。例如一个银行账户系统就需要一个能够读写100字节的数据库，因为100字节就可以表示人们的银行账户。但是GFS不是这样的系统，GFS是为TB级别的文件而生。并且GFS只会顺序处理，不支持随机访问。某种程度上来说，它有点像批处理的风格。GFS并没有花费过多的精力来降低延迟，它的关注点在于巨大的吞吐量上，所以单次操作都涉及到MB级别的数据。

![](/files/-MDXSqnUwJwYGHBLn1RT)

GFS论文发表在2003年的SOSP会议上，这是一个有关系统的顶级学术会议。通常来说，这种会议的论文标准是需要有大量的创新研究，但是GFS的论文不属于这一类标准。论文中的一些思想在当时都不是特别新颖，比如分布式，分片，容错这些在当时已经知道如何实现了。这篇论文的特点是，它描述了一个真正运行在成百上千台计算机上的系统，这个规模远远超过了学术界建立的系统。并且由于GFS被用于工业界，它反映了现实世界的经验，例如对于一个系统来说，怎样才能正常工作，怎样才能节省成本，这些内容也极其有价值。同时，论文也提出了一个当时非常异类的观点：存储系统具有弱一致性也是可以的。当时，学术界的观念认为，存储系统就应该有良好的行为，如果构建了一个会返回错误数据的系统，就像前面（详见3.2）介绍的糟糕的多副本系统一样，那还有什么意义？为什么不直接构建一个能返回正确数据的系统？GFS并不保证返回正确的数据，借助于这一点，GFS的目标是提供更好的性能。

最后，这篇论文还有一个有意思的事情。在一些学术论文中，你或许可以看到一些容错的，多副本，自动修复的多个Master节点共同分担工作，但是GFS却宣称使用单个Master节点并能够很好的工作。

> 学生提问：如果GFS返回错误的数据，会不会影响应用程序？
>
> Robert教授：讽刺的是。有谁关心网上的投票数量是否正确呢，如果你通过搜索引擎做搜索，20000个搜索结果中丢失了一条或者搜索结果排序是错误的，没有人会注意到这些。这类系统对于错误的接受能力好过类似于银行这样的系统。当然并不意味着所有的网站数据都可以是错误的。如果你通过广告向别人收费，你最好还是保证相应的数字是对的。
>
> 另外，尽管GFS可能会返回错误的数据，但是可以在应用程序中做一些补偿。例如论文中提到，应用程序应当对数据做校验，并明确标记数据的边界，这样应用程序在GFS返回不正确数据时可以恢复。