重读GFS的设计

GFS作为经典的作品，但是自己不读原文，永远不会理解全文的意思。
     下面的是我对GFS的体悟：
1.系统架设故障是经常发生的。
2.所处理的文件级别很大，上G级别的文件是常事，而且文件大概为100M左右。
3.大多数的文件是采用append的方式追加到文件结尾的，而不是采用覆盖写的方式，采用这种方式是为了提高写的效率。
4.将应用和文件系统综合考虑，做成的这样的一个GFS 使我们的处理更加灵活。

整个GFS并没有采用标准的ＡＰＩ形式，比如POSIX，但是仍然支持目录这种分层的结构。他支持的API有 create,delete,open,close,read,write这些方法。
Master设计
     GFS采用中心化管理的方式,这样将复杂的设计集中在master即可，这样做也是分布式系统普遍采用的一个最最简单，最最容易的设计，如果采用了去中心化的设计，系统的写性能会提高很多，但是读性能就会牺牲，比如dynamo。
Master存放的是namespace，访问控制信息，文件到chunk的映射。还有chunk所在的位置。

Client设计
    对于GFS这种大数据应用场景，Client不需要cache 文件数据，因为数据太大，cache太占用空间。Client只cache住chunk的metadata，也就是位置信息，当cache过期，或者文件需要被打开的时候。否则Client不用和Master进行交互，节省了一次与Master的交互。
Chunk大小的设计与一致性
    对于Chunk大小设计为64M，为了减少Master的负担，因为首先文件普遍是大文件，如果blocksize 范围在KB 级别的，那么将会导致大量的请求与master进行交互，而且将会产生大量的元数据，Master根本就hold不住。

Chunk的存放位置
    Master会在开始的时候轮询所有的ChunkServer，这种操作一直存在，目的有两个，监控每个节点的状态，第二个得到所有的Chunk的存放位置，并保持实时。

Operation Log
   这个日志对Master 非常重要，他有多个副本，因为如果数据丢失的话，或者机器出现故障，是可以通过Operation Log来重新还原数据的。 Operation Log记录了对metadata的改动，及其时间戳。它定义了并发执行操作的顺序。 oplog有多个副本，而且必须等所有的oplog完成之后，才返回。

对于google的集群而言，机架内的服务器之间的通信能够达到100M/s，所以延迟非常小。

数据流
   当数据写入到Chunkserver的时候，数据流并不是按照控制流流动的，为了减少网络IO瓶颈，数据会先发送到最近的节点S1，然后发送到离S1最近的节点S2，然后是离S2最近的S3。