Google File System论文阅读笔记

最新推荐文章于 2019-04-18 18:03:10 发布

Lyteins

最新推荐文章于 2019-04-18 18:03:10 发布

阅读量388

点赞数

本文链接：https://blog.csdn.net/lyteins/article/details/88761131

版权

试着读一下Google分布式三篇文章。MapReduce之前读过，感觉基础理论上理解起来比较简单，对于其在工程上的如容错处理等精髓待深入学习后再重读一遍。这里记录一下GFS论文里暂时学到的内容。

需求

节点无效是常态，因此需要注意节点的容错、监控以及恢复。
以存储大文件为主，一般为几百MB至几GB。
负载方面，有大内容连续读，小内容随机读，主要以追加式连续写的方式。
需要具有高效性、原子性。
高数据吞吐量比低延迟更加重要。

由客户端、一个master、多个server组成，master负责维护元数据、与server进行心跳通信。
对于一个文件，首先由master切分成多个chunk，每个chunk大小为64MB，有一个64位的handle，并复制至多个replica中保存。

对于文件的传输，分为以下几步：

元数据存于master的内存中，主要包括

namespace由master管理于内存中，对其的修改需要通过master添加互斥锁，保证其原子性。
对于文件的修改，主要存在几个概念：

因此，在进行写操作后：

对于修改数据，主要分为两种：

因此在GFS下更加倾向于追加操作，因为这样更强一致。

在某个chunk修改后，master将该chunk的lease交给某个replica，使其称为primary，对其他replica逐一修改。chunk lease有60秒的任期，未超时时可以向master申请延长时间，超时后master回收lease。

文件追加和文件写入相似

客户端将数据发送至所有replica缓冲区后，向primary发送追加请求
primary判断追加后是否会超过chunk上限，若是的话就先将当前chunk填充满，并通知其他replica执行相同的操作，然后通知客户端在下一块chunk上重试
若空间足够，则primary通知所有replica追加位置的偏移量
操作完成后，primary响应客户端

目标：最大化数据可用；最大化网络带宽利用率
来源：创建chunk；为chunk备份；replica均衡

namespace中不删除，而是重命名为一隐藏名，且带有时间戳
master按时扫描namespace，若发现超出设定天数的隐藏内容，则进行移除
namespace中移除后，对应chunk引用计数减一。master扫描所有chunk发现引用为0的chunk时，在内存中移除有关元数据，并通知replica自行移除

关注