分布式基础——GFS（Google file system）

设计大型分布式系统或大型存储系统的出发点：想获得巨大的性能加成，从而利用数百台计算机的资源同时完成大量的工作。

分片：将数据分隔放在大量的服务器上，从而并行的从多台服务器读取数据。

但是，如果大量的服务器进行分片，故障将常态化。如果有数千台服务器，总会有一台服务器宕机，每天甚至每小时都会发生错误。我们需要一个自动的容错系统。实现容错的最有用的一种方法是复制，只需维护2—3个数据的副本，当其中一个故障了，可以使用另一个。但是，如果复制得到两个副本，在工作的过程中，副本变得不一致了，他们便不再互为副本，获取到的数据也取决于向哪个副本请求数据。这是不一致（inconsistency）问题。

在现实世界中，会构建多副本的分布式系统，提高容错能力。

目标：构建一个大型的、快速的文件系统，这个文件系统是全局有效的，这样各种不同的应用程序都可以从中读取数据。

一种构建大型存储系统的方法是针对某种特定的应用程序构建特定的裁剪的存储系统，但如果另一个应用程序也想要一个大型存储系统，那么又需要重新构建一个存储系统。如果有一个全局通用的存储系统，那么如果一个人存储了大量的数据，其他人也可以申请权限来查看这些数据，因为使用了同一个存储系统。

为获得大容量和高速的特性，每个包含了数据的文件都会被GFS自动分割并存放在多个服务器上；这样读写操作会变得很快，因为可以从多个服务器上同时读取同一个文件，进而获得更高的聚合吞吐量；将文件分割存储还可以在存储系统中保存比单个磁盘还要大的文件。由于在数百台服务器上构建存储系统，我们希望系统有自动的故障修复。

GFS被设计成只在一个数据中心中运行，并没有将副本保存在世界各地，单个GFS仅存在于单个数据中心的单个机房里。理论上讲，数据的多个副本应该彼此之间间隔的远一些，以防止部分不可控因素导致所有副本都失效，但是这种方式实现起来较难，故GFS仅局限在了一个数据中心内。

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

GFS的论文提出了一个异类的观点：存储系统具有弱一致性也是可以的。GFS的目标是提供更好的性能，并不保证返回正确的数据。GFS作为Google——一个搜索引擎的系统，少量的错误并不重要，在上万个搜索结果中丢失几条或搜索结果排序错误重要性并不是那么大。

针对GFS可能会返回错误的数据，我们可以在应用程序中做一些补偿。应用程序可以对数据做校验，并明确标记数据的边界，这样应用程序在GFS返回不正确数据时可以恢复。

GFS中的master是active-standby模式，故只有一个master节点在工作。master节点保存了文件名和存储位置的对应关系。GFS还有大量的chunk服务器，可能会有数百个，每一个chunk服务器上都有1~2块磁盘。

master节点用来管理文件和chunk的信息，chunk服务器用于存储实际的数据。master节点知道每一个文件对应的所有chunk的ID，每个chunk为64MB大小，它们共同构成一个文件。master节点知道文件的第一个chunk存储在哪，第二个chunk存储在哪，当需要读取文件中的任意部分时，我们需要向master节点查询对应的chunk在哪个服务器上，然后直接从chunk服务器上读