GFS,顾名思义就是谷歌文件系统,和Big Table,Map Reduce并称谷歌三驾马车。 大部分谷歌服务的基石(Search, Cloud Drive, Gmail etc.)
图片
最底层是文件系统,在之上是将数据模型抽象出来,便于很好的使用,这就是bigTable,在之上是算法, 算法除了访问数据模型外,还能够直接访问文件系统,最上面就是各类应用了
源头是如何保存一个文件?
图片
保存文件需要两部分:
metadata:包括文件信息和索引 file content:具体的文件内容
进一步如何保存大文件
图片
此时索引信息会保存的粒度更粗,存的是chunk,每个chunk是64M
再进一步,怎么保存超大文件
图片
确定啊很明显:chunkServer的变化都需要将其告诉master
怎么进行改进?
图片
系统设计中非常关键的点:耦合和聚合,将属于它的放到它那,不属于的放到其他地方
将master保存每一块在哪个服务器上,每个服务器的索引放到chunkServer中
图片
可以对每个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负责协调开始写入,都写成功后,告诉客户端
如果写入出错了怎么办?如果引入出错处理机制,会引入更多的问题,往往解决一个问题会带来更多的问题,因此系统在设计过程中,尽可能只提供最简单的功能,由客户端来负责重试