嘉定网站建设哪家好,自己做团购网站怎么样,icodepython基础教程,wordpress照片归类GFS 原文#xff1a;https://zhuanlan.zhihu.com/p/113161014 搬运用于参考学习 概述
存储#xff08;Storage#xff09;是一个非常关键的抽象#xff0c;用途广泛。
GFS 论文还提到了很多关于容错、备份和一致性的问题。
GFS 本身是 Google 内部一个很成功的实用系统https://zhuanlan.zhihu.com/p/113161014 搬运用于参考学习 概述
存储Storage是一个非常关键的抽象用途广泛。
GFS 论文还提到了很多关于容错、备份和一致性的问题。
GFS 本身是 Google 内部一个很成功的实用系统其关键点被很好的组织到一块发表成为了学术论文从硬件到软件涵盖了很多问题值得我们学习。
为什么难
性能High Performance– 分片sharding
分布式系统自然想利用大量的机器提供成比例的性能于是通常将数据分散到不同的机器上以并行读取。我们称之为分片Sharding。但分片一多故障率就上来了。
故障Faults— 容错tolerance
故障多了就需要进行自动容错。最简单直接、通常也最有效的容错方法就是备份Replication或译为冗余、副本。如果副本是可修改的就需要定期同步这就引出了一致性的问题。
副本Replication— 一致性Consistency
当然通过精心的设计可以维持系统的一致性但这就意味着你需要损失性能。
一致性Consistency— 低性能Low Performance
这有点类似于反证法最后推出了矛盾说明了构建分布式存储系统这件事的难点所在。在实践中在给定场景性下我们有更多的取舍余地也就让设计一个合理的系统成为可能。 一致性
强一致性
即尽管存储系统中有很多副本、很多机器但是对外表现的行为却像单机一样所有客户端都能够读到其他客户端之前所写内容。这个行为或者说保证看起来很简单、自然但在分布式环境中这确非易事。这部分想详细了解的可以看我翻译的一篇关于 CAP 的经典文章。
糟糕设计
为了使得所有副本保持一致性可以在在客户端做同步每次写操作都并行的写多个备份。每个备份服务器接收到的写操作顺序可能并不一致从而造成备份的不一致性。 GFS
在谷歌三篇著名论文MapReduceGFSBigtable出来之前一些分布式的理论大多停留在学术界中谷歌由于面临海量数据youtube 视频、网页索引等等的处理、存储和访问需求最早开发出了实用的大规模的分布式框架。
特点
体量大速度快BigFast海量数据的快速存取全球部署Global不同 site 的数据访问和共享分片Sharding多客户端并发访问增大吞吐自动恢复Auto recovery机器太多自动化运维
不过接下来我们只讨论具有以下限定的 GFS
部署在单个数据中心datacenter仅供内部使用不用过多考虑安全性大数据的顺序读写而非随机访问
GFS 可贵之处在于他是经过实践检验、部署过上千台机器的工业级系统颠覆了之前学术界中很多的经典设计认知比如
为了保证数据访问不出错需要提供强一致性保证GFS 仅提供某种弱一致性为了系统的可靠性用多机来保证主节点的可靠性GFS 使用了单点 Master
系统角色
Clients客户端通过接口访问系统。
Master保存命名空间以及元信息
ChunkServer存储节点。
Master 数据结构
Master 数据
主要有以下两张表Map
文件名到 chunk 句柄的映射filename → array of chunk handlesnvchunk 句柄到 chunk元信息的映射包括副本位置chunk 版本号主 chunk租约过期时间
chunk handle → list of chunk servers(v)/version(nv)/ Primary(v) / lease expire time(v)
这两个数据结构都存在内存RAM中。但为了宕机恢复需要把一些信息标记为 nvnon-volatile写到硬盘上即
读取从内存中读即可。写入修改内存同时在磁盘上记操作日志 LOG 快照CheckPoint。
对于另外一些信息标记为vvolatile根据从 chunkserver 来的心跳构建即可。
使用日志Log而不是数据库DB来记录操作信息是因为在磁盘上前者更快。但如果操作特别多恢复起来会很慢。能不能压缩因此有了快照snapshot将操作日志所对应的内存状态通过某种格式比如说B-tree做一个快照。两者结合将历史息用快照存储、最近一段信息用操作日志存储。这样既提高了空间利用率也降低了操作延迟。
读写流程
读取 READS
文件名、偏移量 –请求 → MasterMaster –回应 → Chunk 句柄Chunk 副本地址列表Client 会缓存该信息客户端向某个副本比如物理最近所在的 chunk sever 请求数据chunk server 返回相应数据
QA
待访问数据跨 chunk 怎么办GFS 会提供客户端 lib自动将其拆成多次请求。客户端不需要关心这些细节。
写入 WRITES
这里只讲一下 Record Appends分两种情况
Master 上没有主副本信息No Primary
找到所有最新副本即需要大于等于 Master 所知最新版本号
Master 选择其中一个作为主副本Primary其他的即为从副本SecondaryMaster 增加版本号Master 将新版本号同步给所有主从副本同时给主副本一个租约。Master 将版本号持久化。
Master 有主副本信息
Primary 选定 offset由于 append 存在并发Primary 负责将并发的 append 安排一个写入顺序即给每个 append 一个不同的 offset。所有副本被通知在该 offset 写入数据。如果所有副本回复 Primary 写成功Primary 回复 Client 写成功任何一个副本写失败则 Primary 回复 Client 写失败。Client lib 会自动重试整个 Append 过程。
QA
如果 Client 写失败则最终不同副本可能会存在不一致的区域有些写成功了有些写失败了。但只要最终写成功了会保证在返回的 offset 处所有的数据都一致。中间写失败形成的不一致会在读取的时候被跳过。同步数据时Client 只会同步给最近的一个 replica然后该 replica 进一步同步给其他 replica。如此链式同步以避免交换机带宽瓶颈。只有在 Master 认为所请求 chunk 没有主副本时才会更新版本号。如果能在其内存表中找到主副本地址则直接返回给 Client。当发生网络分区时Primary 和 Client 可以正常连接但是与 Master 失联。租约到期时没有收到Primary 心跳Primary 通过向 Master 心跳来续约Master 就会认为 Primary 宕机从而重新选择一个 Primary。此时就会形成 split brain。这种情况就比较难办了。一个解决办法是Master 等旧 Primary 租约过期旧 Primary 也知道自己的租约过期时间没有正常续约时会自动失去 Primary 身份后再去选择一个新 Primary。如果要 Append 的某个文件还不存在怎么办Master 会初始化一个版本号然后随机选定一个 Primary 和几个 secondaries然后回复给 Client。
参考笔记
6.824 2020 视频笔记三GFShttps://zhuanlan.zhihu.com/p/113161014
GFS —— 取舍的艺术https://www.qtmuniao.com/2019/05/26/gfs/
gfs原理https://oserror.com/distributed/gfs/
参考代码
a simple GFS: https://github.com/lishuai87/asgfs
论文
英文原文The Google File System
中文翻译The Google File System
