深入浅出Google File System
GFS是什么
GFS，顾名思义就是谷歌文件系统，和Big Table，Map Reduce并称谷歌三驾马车。 大部分谷歌服务的基石（Search, Cloud Drive, Gmail etc.）
图片
最底层是文件系统，在之上是将数据模型抽象出来，便于很好的使用，这就是bigTable，在之上是算法， 算法除了访问数据模型外，还能够直接访问文件系统，最上面就是各类应用了
gfs从哪里来
源头是如何保存一个文件？
图片
保存文件需要两部分：
metadata：包括文件信息和索引 file content：具体的文件内容
进一步如何保存大文件
图片
此时索引信息会保存的粒度更粗，存的是chunk，每个chunk是64M
再进一步，怎么保存超大文件
图片
确定啊很明显：chunkServer的变化都需要将其告诉master
怎么进行改进？
图片
系统设计中非常关键的点：耦合和聚合，将属于它的放到它那，不属于的放到其他地方
将master保存每一块在哪个服务器上，每个服务器的索引放到chunkServer中
GFS容错机制
- 怎么发现数据损坏
图片
可以对每个block保存个checksum，对于1T的数据，只有64M，完全可以放到内存中
如果数据损坏的话呢，Chunk Server就找Master恢复数据
图片
为了防止数据的丢失，就做冗余存储，每个chunk存3份，在chunkServer的选择上，尽可能放到不同的机房，然后同机房也放到不同的机架上
图片
master是关键，会同时发送心跳检查Chunk Server是否运行正常。如果有服务器挂掉的话就向Master申请恢复
图片
心跳的设计：可能是由于master和server之间网络不通，这个时候，master会求助其他的server，让他们再去ping下失联的server
图片
当发现副本数小于3个，会启动修复进程进行修复，修复的优先级
怎么应对热点
图片
负载均衡
核心读写操作
好了，我们构建这么一个庞大的系统最后不就是要读和写嘛，现在我们看看GFS是如何读写的。读数据时Client先向Master要到Chunk信息，然后去ChunkServer取数据
图片
写文件的时候呢，也是先找到Master Server要到信息，然后找到距离最近的Chunk Server。由其带领其他ChunkServer一起写数据。如果图中有任何一步出现错误则中止写入，返回错误
图片
写的时候是往最近的server写，然后server再接收到数据后就往其他server发送，在写入的时候呢，是先缓存下来，最后都缓存好了，再写入到磁盘，好处是减少出错的概率，因为一旦缓存好，再写出错的几率就大大减少了。
第3步是cache，都cached后，由primary server负责协调开始写入，都写成功后，告诉客户端
如果写入出错了怎么办？如果引入出错处理机制，会引入更多的问题，往往解决一个问题会带来更多的问题，因此系统在设计过程中，尽可能只提供最简单的功能，由客户端来负责重试