深入浅出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负责协调开始写入,都写成功后,告诉客户端
如果写入出错了怎么办?如果引入出错处理机制,会引入更多的问题,往往解决一个问题会带来更多的问题,因此系统在设计过程中,尽可能只提供最简单的功能,由客户端来负责重试