The Google File System 读书笔记

reference : GFS

中文: The Google File System中文版

1.读书感悟

之前看的时候都是简单的浏览了一下中文的翻译, 也没有细细的去分析解剖 这篇原文. 之前因为在心里一直惦记着, 所以就想拿出来看看, 谁知道这对我简直当头一棒的打击. 同时也是敲醒了我自己, 我是如此的无知. 这篇文章主要是基于google 在03年上市之前, 在快速的数据增长之前做了历史的性的基础设施奠基. (想想自己03年还是个傻得很的少年) 另外文章也是对大规范的分布式 的一些痛点: 错误容忍性/ 数据的可恢复/ 可拓展性 方面来进行细节的描述.

2.下面有几个需要解决的标准:

解决各种组件的的问题. 在大规模分布式系统中, 问题是常态. 所以需要有良好的错误容忍性 和自动可恢复

设计一个好的通用的标准能够支持海量的数据.

大部分的数据都是通过append (追加) 而替代覆盖的操作.

可拓展的api .

3.整体架构

一个master 多个chunk server 的主从结构.同时能够支持多个client 并发访问

存储的文件分割成固定大小的chunk , chunkserver 中存储大小固定大小的chunk 同时记录着每块chunck 的字节范围方便读写.

master 管理着整个文件系统的metadata, namespace, 访问权限, 文件和chunk 的映射, chunk的位置信息. chunk的管理. (增删) , chunk 在不同的server 之间复制(转移), 心跳感知server 的变化.

API

client 会保存chunk 的metadata 方便下次能够不需要通过master 快速找到file 的位置.

3.1 chunk

这里我对chunk比较感兴趣单独罗列出来聊聊. 首先是大小. 64MB, 比正常在磁盘空间的block都要大得多. 这样的好处主要是体现在能够一次网络请求获得一个大的chunk 减少网络开销. 同时能够降低master 的开销. 因为client 能够存放更多的chunk的信息 , 减少了磁盘碎片的(但是chunk 内部也会有碎片 可能是浪费的)

这样设计就可能导致热点(Hotspot)问题, 同一时间成千上万的请求都访问同一个chunk 这样会导致局部负荷过载, 解决的方式可以通过加大复制数(replica) (不知道能不能自动的做. 比如某个chunk 是Hotspot, 就先拆分 然后在重新replica), 另外的解决办法就是通过其他的client 端来获取(这个就很想p2p , 这个就非常非常有意思 也想到了快播好像就是这样做了一个东西出来)

3.2 操作日志

operation Log 几乎是是整个系统的命脉, 因为他记录了metadata 的改变,所以能够通过log 来做恢复, 也能够通过它来实现并发的操作. 同时为了保证log 的有效性 也是会存储在多个不同的节点上面以便丢失. 当master需要故障恢复 的时候需要依赖log 的帮助. 首先master 会自动的创建checkpoint(相当于一种snapshot ) 同时 再重现 checkpoint 之后的log 这样保证恢复的时间能够更快.

3.3 弱一致性的模型

这里有两个概念需要了解的就是, 一致: 读取的数据在那个时间那个replica 都是相同的话就称为一致 (但是这个跟单点的数据库的一致性有一个不太一样的地方 , 主要是引入了replica , 这个时候读取的时候可能会有一个时间差, 就是不一定是罪行的, 所以最佳的操作是部分一致性) 但是因为写的时候是保证原子性, 同时要加入锁来管理, 所以能够保证一致

另外这里面提到的(defined, undefined)我仍然没有了解透. (这里可能还需要琢磨一下)

这里有一个点就是, client 是保存了replica的location , 所以失效的replica会不会返回失效的数据而是返回最新的location.

在实现的方面, 尽可能的用上了追加, checkpoint 和checksum / self-identifying (最后在第五节高可用中 疯狂提到)

4.系统交互

这里主要讲述了, master 和chunkserver 之间是如何通讯的.这个章节我比较关心的部分是lease 的机制.(这个之前我就一直看到, 这里详细的给我解释了一遍)

Lease 租约机制 主要是为了减轻master 的负担, 通过下放 给主chunk 权利, 主chunk 通过对操作序列化, 同时能够同步到其他replica. 这个时候master 只需要跟主chunk 保持通讯 并不需要跟其他replica通讯(特指这一次写的操作), 另外这个租约是按照时间为期限,主chunk 可以申请延长, 同时master 能够控制取消和授予.(很有意思的样子)

(另外我的理解这个租约也是有一种ticket的作用, 能够分配下去让client 对某一个replica 操作的ticket. )

追加的操作. 多次的追加以确保能够成功, 但是不完全能够保证一致. 中间还有一个batch 的过程.

5. 感受

总得来讲 有很多点我都在不同的地方看过, 都是一样的设计, 所以看得时候并不陌生, 但是重点可能是这篇文章的历史价值确实非常的高, 所以我也不得不重新审视自己的学习方式到底是否有误, 自己的学习是否能够抓紧这个时代的脚步, 至少我不能落后.这个就是我的立足点.