存储(Storage)是一个非常关键的抽象,用途广泛。
GFS 论文还提到了很多关于容错、备份和一致性的问题。
GFS 本身是 Google 内部一个很成功的实用系统,其关键点被很好的组织到一块发表成为了学术论文,从硬件到软件,涵盖了很多问题,值得我们学习。
想详细了解 GFS,也可以看我之前的GFS 论文笔记。
作者:青藤木鸟 https://www.qtmuniao.com/2020/03/14/6-824-vidoe-notes-3-gfs/ , 转载请注明出处
性能(High Performance)–> 分片(sharding)
分布式系统,自然想利用大量的机器提供成比例的性能,于是通常将数据分散到不同的机器上,以并行读取。我们称之为:分片(Sharding)。但分片一多,故障率就上来了。
故障(Faults)—> 容错(tolerance)
故障多了,就需要进行自动容错。最简单直接、通常也最有效的容错方法就是:备份(Replication,或译为冗余、副本)。如果副本是可修改的,就需要定期同步,这就引出了一致性的问题。
副本(Replication)—> 一致性(Consistency)
当然,通过精心的设计,可以维持系统的一致性,但这就意味着你需要损失性能。
一致性(Consistency)—> 低性能(Low Performance)
这有点类似于反证法,最后推出了矛盾,说明了构建分布式存储系统这件事的难点所在。在实践中,在 给定场景性 下,我们有更多的取舍余地,也就让设计一个合理的系统成为可能。
即,尽管存储系统中有很多副本、很多机器,但是对外表现的行为却像单机一样:所有客户端都能够读到其他客户端之前所写内容。这个行为,或者说保证,看起来很简单、自然,但在分布式环境中,这确非易事。这部分想详细了解的可以看我翻译的一篇关于 CAP 的经典文章。
为了使得所有副本保持一致性,可以在在客户端做同步:每次写操作,都并行的写多个备份。每个备份服务器接收到的写操作顺序可能并不一致,从而造成备份的不一致性。
在谷歌三篇著名论文(MapReduce,GFS,Bigtable)出来之前,一些分布式的理论大多停留在学术界中,谷歌由于面临海量数据(youtube 视频、网页索引等等)的处理、存储和访问需求,最早开发出了实用的大规模的分布式框架。
不过接下来,我们只讨论具有以下限定的 GFS:
GFS 可贵之处在于他是经过实践检验、部署过上千台机器的工业级系统,颠覆了之前学术界中很多的经典设计认知,比如:
Clients:客户端,通过接口访问系统。
Master:保存命名空间以及元信息
ChunkServer:存储节点。
Master 数据:
主要有以下两张表(Map):
文件名到 chunk 句柄的映射:filename –> array of chunk handles(nv)
chunk 句柄到 chunk元信息的映射(包括副本位置,chunk 版本号,主 chunk,租约过期时间):chunk handle —> list of chunk servers(v)/version(nv)/ Primary(v) / lease expire time(v)
这两个数据结构都存在内存(RAM)中。但为了宕机恢复,需要把一些信息(标记为 nv:non-volatile)写到硬盘上,即:
读取,从内存中读即可。
写入,修改内存同时在磁盘上记操作日志( LOG)+ 快照(CheckPoint)。
对于另外一些信息(标记为v:volatile),根据从 chunkserver 来的心跳构建即可。
使用日志(Log)而不是数据库(DB)来记录操作信息,是因为在磁盘上,前者更快。但如果操作特别多,恢复起来会很慢。能不能压缩?因此有了快照(snapshot):将操作日志所对应的内存状态通过某种格式(比如说B-tree)做一个快照。两者结合:将历史息用快照存储、最近一段信息用操作日志存储。这样既提高了空间利用率,也降低了操作延迟。
Q&A:
写入 WRITES:
这里只讲一下 Record Appends,分两种情况,
Q&A:
为了实现一致性,可能需要类似两阶段提交的协议,但无疑会降低性能。
随着数据量的增大,元信息变多,Master 的内存可能会装不下,也就是 GFS 的单点瓶颈问题。
Master 恢复需要人工接入,导致系统宕机恢复可能需要数十分钟。
我来评几句
登录后评论已发表评论数()