阐明
本系列文章是对赫赫有名的 MIT6.824分布式系统课程 的翻译补充和学习总结，算是本人一边学习一边记录了。
如有疏漏谬误，还请斧正：）
继续更新ing。。。
翻译&补充
论文
The Google File System
Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung
SOSP 2003
为什么咱们须要读这篇论文？
分布式存储是很重要的概念
- 接口/语义 应该是什么样子的？
- 外部是如何工作的？
GFS论文笼罩了6.824中的很多主题：并行，容错，复制，一致性
良好的零碎论文——细节从利用始终到网络都笼罩到
胜利的理论利用的设计
为什么分布式存储很难？
高性能 --> 多台机器间数据分片
多台服务器 --> 常常出错
容错 --> 复制
复制 --> 不统一
更好地一致性 --> 低性能
对于一致性，应该怎么解决？
现实的模型：和一台服务器一样的行为表现
服务器应用硬盘存储
服务器在同一时刻只执行一条客户的操作（即使是并发的）
读之前所写，即使服务器解体或重启
因而：假如C1和C2并发地写，等到写操作结束，C3和C4读。它们会取得什么？
C1: Wx1
C2: Wx2
C3: ---- Rx?
C4: -------- Rx?
答复：1或者2，然而C3和C4会看到雷同的值。
这是一个“强”一致性的模型。
然而一台独自的服务器容错性很差。
为了容错的复制，很难实现强一致性
一个简略，但有问题的复制计划：
- 两个复制的服务器，S1和S2
- 多个客户端向两台服务器，并行发送写申请
- 多个客户端向其中一台，发送读申请
在咱们的示例中，C1和C2的写申请可能会以不同的程序达到两台服务器
- 如果C3从S1读取，可能会看到x=1
- 如果C4从S2读取，可能会看到x=2
或者如果S1承受了一个读申请，然而在发送写申请到S2时，客户端解体了，会怎么样？
这不是强一致性！
更好的一致性通常须要通信，来保障复制集的统一 —— 会很慢！
性能和一致性之间须要衡量很多，当前会看到
GFS
内容：
很多谷歌的服务须要大型疾速的对立文件存储系统，比方：Mapreduce，爬虫/索引，日志存储/剖析，Youtube（？）
全局来看（对于一个独自的数据中心）：任何一个客户端能够读取任意文件，容许多个利用之间共享数据
在多个服务器/硬盘上自动化“切片”每个文件，晋升并行的性能，减少空间可用度
谬误的主动复原
每次部署只有一个数据中心
只有谷歌的利用和用户
旨在大文件的的程序操作；读或者追加。不是存储小数据的低提早DB
在2003年有什么翻新点？他们是怎么被SOSP承受？
不是分布式、分区、容错这些根本的思维
大规模
在工业界的理论利用教训
弱一致性的胜利案例
独自master的胜利案例
架构总览
客户端（库，RPC —— 但不像Unix文件系统那样可见）
每个文件切分为独立的64MB的数据块
数据块服务器，每个数据块复制3份
每个文件的数据块们散布在多个数据块服务器上，用于并行读写（比方，MapReduce），并且容许大文件只有一个master（！），master也会复制
工作的划分：master负责写名称，数据块服务器负责写数据
Master的状态
在RAM中（速度，应该是有点小的）：
在硬盘上：
- 日志
- 检查点
为什么有日志和检查点？
为什么是大的数据块？
当客户端C想要读数据，是什么步骤？
- C发送文件名和偏移量到master M（如果没有缓存的话）
- M找到这个偏移量的数据块handle
- M回复最新版本的数据块服务器的列表
- C缓存handle和数据块服务器列表
- C发送申请到最近的数据块服务器，包含数据块handle和偏移量
- 数据块服务器从硬盘上读取数据块文件，并返回
master怎么晓得数据块服务器含有一个指定的数据块？
当C想要在记录后追加，是什么步骤？
论文的图2
- C询问M文件的最初一个数据块
- 如果M发现数据块没有主记录（或者租约过期）
2a. 如果没有写数据块服务器的最新版本，谬误
2b. 从最新的版本中抉择主节点和备份节点
2c. 版本号减少，写到硬盘的日志上
2d. 通知主记录和备份的记录他们是谁，以及新版本
2e. 在硬盘上复制地写入新版本 - M通知C主记录和备份记录
- C向全副发送数据（只是临时的。。。），并期待
- C通知P须要追加
- P查看租约是否过期，数据块是否有空间
- P确定偏移量（数据块的完结）
- P写数据块文件（一个Linux文件）
- P通知所有备份节点偏移量，通知它们须要追加到数据块文件
- P期待所有备份节点的回复，超时则为谬误，例如：硬盘空间有余
- P通知C ok或谬误
- 如果出错，C从头重试
GFS提供给客户端的是什么样的一致性保障
须要通知利用以某种模式应用GFS。
这是一种可能性：
如果主节点通知客户端一条记录胜利追加，则所有的读者随后关上这个文件，都能够看到追加的记录。
（然而并非失败的追加就不可见，或者说，所有的读者都会看到雷同的文件内容，雷同程序的记录）
咱们怎么晓得GFS是否实现了这些保障？
看它对不同种谬误的解决形式：解体，解体+重启，解体+代替，信息失落，分区。
请想一想GFS是怎么保障要害个性的。
* 一个追加的客户端在不适合的时刻失败了，怎么办？
有没有不适合的时刻存在？
* 一个追加客户端缓存了一个过期的（谬误的）主节点，怎么办？
* 一个读的客户端缓存了一个过期的备份节点列表，怎么办？
* 一个主节点解体+重启，会导致文件的失落吗？
或者遗记哪些数据块服务器存储指定的数据块？
* 两个客户端在同一时间进行记录追加。
他们会笼罩彼此的记录吗？
* 主节点在向所有备份节点发送追加申请时，主节点解体，会怎么样？
如果一个备份节点没有看到追加申请，会被选为新的主节点吗？
* 数据块服务器S4存储旧的过期的数据块备份，是离线的。
主节点和其余存活的备份节点都解体。
S4复活（在主节点和备份节点之前）。
master会抉择S4（蕴含过期数据块）作为主节点吗？
是抉择含有过期数据的节点作为左节点适合，还是抉择没有备份的节点？
* 如果备份节点总是写入失败，主节点应该怎么做？
比方，死机，硬盘空间有余，或硬盘故障。
主节点应该从备份节点列表中抛弃该节点吗？
而后向追加记录的客户端返回胜利？
或者主节点始终发送申请，认为申请都失败，
给客户端的每个写入申请都返回失败？
* 如果主节点S1是沉闷的，服务于客户端的申请，然而master和S1之间的网络不通？
“网络分区”。
master会抉择一个新的主节点吗？
这时候会存在两个主节点吗？
如果追加申请发送给一个主节点，读申请发送给另一个，是否突破了一致性的保障呢？
“脑裂”
* 如果有一个分区的主节点在解决服务端的追加申请，然而它的租约到期了，master抉择了一个新的主节点，这个新的主节点会有之前主节点解决的最新的数据吗？
* 如果master失败会怎么样？
替换后的master晓得之前master的所有信息吗？
比方，每个数据块的版本号？主节点？租约过期工夫？
* 谁判断master是否死机且须要被替换？
master的备份会ping master吗？如果没有回应则接替它？
* 如果整个环境断电了，会怎么样？
如果电力复原，所有的机器会重启，会怎么？
* 假如master想要创立一个新的数据块备份。
可能因为备份太少了。
如果它是文件的最初一个数据块，正在被追加。
新的备份怎么保障没有谬误追加？毕竟它还不是一个备份节点。
* 存不存在一个场景，会突破GFS的保障？
例如，追加胜利，然而随后的读者没有看到这条记录。
所有master的备份永恒地失落状态信息（永恒硬盘谬误）。可能更早：后果会是没有答复，而不是谬误的数据。“故障-进行”
某个数据块的所有数据块服务器失落硬盘文件。又是，“故障-进行”；并不是最坏的后果
CPU，RAM，网络或硬盘呈现一个谬误值。校验和会查看出一些状况，但不是全副
时钟没有正确地同步，所以租约没有失常工作。所以，会存在多个主节点，可能写申请在一个节点上，读申请在另一个节点上。
GFS容许哪些利用的不标准行为？
所有的客户端都会看到一样的文件内容吗？会不会一个客户端能够看见一条记录，然而其余客户端看不见？一个客户端读取文件两次是看见雷同的内容吗？
所有的客户端都能够看到雷同程序的追加记录吗？
这些不标准行为会为利用带来麻烦吗？
比方MapReduce？
怎么样能力没有异样 —— 强一致性？
例如，所有的客户端看到雷同的文件内容。
很难给出一个实在的解答，不过有一些注意事项。
- 主节点该当检测反复的客户端写申请。或者客户端不该当发送这种申请。
- 所有的备份节点应该实现每个写操作，或者全副不实现。或者先暂定写入，直到所有节点确定再实现写入。只有所有节点批准实现才进行写入操作！
- 如果主节点解体，一些备份节点会谬误最初一部分操作。新的主节点会和所有的备份节点通信，找出最近的所有操作，并同步给其余备份节点。
- 防止客户端从过期的前备份节点读取，或者所有的节点必须与主节点通信，或者所有的备份节点该当也有租约。
你们会在试验3和4看到这些内容！
性能（图表3）
读的大量聚合吞吐（3个复制集，拆开）
- 16个数据服务器，总共 94MB/s 或者每个数据块服务器 6MB/s，这样不错吧？一个硬盘的程序吞吐量大概为 30MB/s，一个网卡的大概在 10MB/s
- 靠近网络饱和（交换机链路）
- 所以：独自服务器的性能是低的，然而扩展性不错。那一个更重要？
- 表格3展现了GFS产品 500MB/s，是很高的
不同文件的写是比可能的最大值要低，作者认为是网络的影响（然而没有具体阐明）
单个文件的并发追加，受限于存储最初一个数据块的服务器
15年后难以预料，例如，硬盘的速度有多快？
一些须要思考的问题
怎么样可能良好地反对小文件？
怎么样能良好地反对千万级别的文件？
GFS能够成为宽泛应用的文件系统吗？在不同的城市有备份？在同一个数据中心有多个备份，容错性不高！
GFS从谬误复原须要多久？一个主节点/备份节点的谬误须要多久？master的谬误呢？
GFS怎么应答迟缓的数据块服务器？
与GFS工程师的回顾性对话：
文件数目是最大的问题
- 最终的数目是图表2的1000倍
- 在master的内存中存储不下
- master垃圾回收时，扫描所有的文件和数据块，很慢
千级别的客户数量会给master的CPU带来很大的压力
利用须要以合乎GFS语义和限度的形式进行设计
master的故障复原最后是齐全人工实现，须要10分钟左右
BigTable是多个小文件的解决方案，Colossus能够在多台master上分片master数据
总结
性能，容错，一致性的案例钻研，为MapReduce利用定制
好的想法：
- 全局的文件集群零碎作为一个基础设施
- 将命名（master）和存储（数据块服务器）拆散
- 并行吞吐的分片
- 大的文件/数据块，升高开销
- 主节点用于程序写
- 租约，为了避免数据块服务器的主节点脑裂
有余的中央：
单个master的性能，耗尽内存和CPU
数据块服务器对于小文件并不高效
master没有主动的故障切换
或者一致性还是比拟弱