从 GFS 失败的架构设计来看一致性的重要性(3)

简介: 从 GFS 失败的架构设计来看一致性的重要性(3)

6.原子记录追加(Atomic Record Appends)

Record Appends在论文中被称之为原子记录追加(Atomic Record Appends),这个接口也 遵循基本的变更流程,有一些附加的逻辑:客户端把数据推送给所有的副本后,客户端发请求 给首要副本,首要副本收到写入请求后,会检查如果把这个record附加在尾部,会不会超出块 的边界,如果超过了边界,它把块中剩余的空间填充满(这里填充什么并不重要,后面我们会 解释这块),并且让其他的二级副本做相同的事,再告述客户端这次写入应该在下一块重试。 如果记录适合块剩余的空间,则首要副本把记录追加尾部,并且告述其他二级副本写入数据在 同样的位置,最后通知客户端操作成功。


微信图片_20220123182307.jpg



原子性

讲完架构和读写流程,我们开始分析GFS的一致性,首先从原子性开始分析。


Write和Atomic Record Append的区别 前面讲过,如果一次写入的数量跨越了块的边界,那么会分解成多个操作,writ e和record append在处理数据跨越边界时的行为是不同的。我们举例2个例子来说明一下。


例子1,文件目前有2个chunk,分别是chunk1, chunk2。

Client 1要在54MB的位置写入20MB数据。这写入跨越了边界,要分解成2个操作,第一个操 作写入chunk1最后10 MB,第二个操作写入chunk2的开头10MB。Client 2也要在54MB的位置写入20MB的数据。这个写入也跨越边界,也要分解为2个操作, 作为第三个操作写入chunk1最后10 MB,作为第四个操作写入chunk2的开头10MB。

2个客户端并发写入数据,那么第一个操作和第三个操作在chunk1上就是并发执行的,第二个 操作和第四个操作在chunk2上并发执行,如果chunk1的先执行第一操作再执行第三个操作, chunk2先执行第四个操作再执行第二个操作,那么最后,在chunk1上会保留client 1的写入的 数据,在chunk2上保留了client 2的写入的数据。虽然client 1和client 2的写入都成功了,但最 后既不是client 1想要的结果,也不是client 2想要的结果。最后的结果是client 1和client 2写入 的混合。对于client 1和client 2来说,他们操作都不是原子的。


例子2,文件目前有2个chunk,分别是chunk1, chunk2。

Client 要在54MB的位置写入20MB数据。这写入跨越了边界,要分解成2个操作,第一个操作 写入chunk1最后10 MB,第二个操作写入chunk2的开头10MB。chunk1执行第一个操作成功 了,chunk2执行第二个操作失败了,也就是写入的这部分数据,一部分是成功的,一部分是 失败的,这也不是原子操作。


接下来看record append。由于record append最多能写入16MB的数据,并且当写入的数据量 超过块的剩余空间时,剩余的空间会被填充,这次写入操作会在下个块重试,这2点保证了 record append操作只会在一个块上生效。这样就避免了跨越边界分解成多个操作,从而也就 避免了,写入的数据一部分成功一部分失败,也避免了并发写入数据混合在一起,这2种非原 子性的行为。


微信图片_20220123182322.jpg


GFS原子性的含义

所以,GFS的原子性不是指多副本之间原子性,而是指发生在多chunk上的多个操作的的原子性。可以得出这样的推论,如果Writ e操作不跨越边界,那么没有跨越边界的writ e操作也满足GFS 所说的原子性。


GFS多副本不具有原子性

GFS一个chunk的副本之间是不具有原子性的,不具有原子性的副本复制,它的行为是:

一个写入操作,如果成功,他在所有的副本上都成功,如果失败,则有可能是一部分副本 成功,而另外一部分失败。


在这样的行为如下,失败是这样处理的:

  • 如果是write失败,那么客户端可以重试,直到write成功,达到一致的状态。但是如果在 重试达到成功以前出现宕机,那么就变成了永久的不一致了。
  • Record Append在写入失败后,也会重试,但是与writ e的重试不同,不是在原有的off set 上重试,而是接在失败的记录后面重试,这样Record Append留下的不一致是永久的不一 致,并且还会有重复问题,如果一条记录在一部分副本上成功,在另外一部分副本上失 败,那么这次Record Append就会报告给客户端失败,并且让客户端重试,如果重试后成 功,那么在某些副本上,这条记录就会成功的写入2次。


我们可以得出,Record Append保证是至少一次的原子操作(at least once atomic)。


微信图片_20220123182338.jpg


一致性

GFS把自己的一致性称为松弛的一致性模型(relaxed consistency model)。这个模型分析元 数据的一致性和文件数据的一致性,松弛主要是指文件数据具有松弛的一致性。

元数据的一致性
元数据的操作都是由单一的mast er处理的,并且操作通过锁保护,所以是保证原子的,也保 证正确性的。

文件数据的一致性

在说明松弛一致性模型之前,我们先看看这个模型中的2个概念。对于一个文件中的区域:

  • 如果无论从哪个副本读取,所有的客户端都能总是看到相同的数据,那么就叫一致的 (consist ent );
  • 在一次数据变更后,这个文件的区域是一致的,并且客户端可以看到这次数据变更写入的 所有数据,那么就叫界定的(defined)。


GFS论文中,用下面的这个表格总结了松弛一致性:



image.png


分别说明表中的几种情况:

1.在没有并发的情况下,写入不会有相互干扰,成功的写入是界定的,那么必然也就是一致的

2.在有并发的情况下,成功的写入是一致的,但不是界定的,也就是我们前面所举的例子2。

3.如果写入失败,那么副本之间就会出现不一致。

4.Record Append能够保证是界定的,但是在界定的区域之间夹杂着一些不一致的区域。 Record Append会填充数据,不管每个副本是否填充相同的数据,这部分区域都会认为是 inconsist ent 的。


微信图片_20220123182405.jpg



相关文章
|
2月前
|
网络协议 中间件 数据库
Zookeeper学习系列【三】Zookeeper 集群架构、读写机制以及一致性原理(ZAB协议)
Zookeeper学习系列【三】Zookeeper 集群架构、读写机制以及一致性原理(ZAB协议)
94 0
|
11月前
|
消息中间件 存储 Cloud Native
《生来创新-金融级云原生》——1 金融企业拥抱云原生的问题与冲突 ——1.7问题 7:云原生架构对交易一致性如何应对?
《生来创新-金融级云原生》——1 金融企业拥抱云原生的问题与冲突 ——1.7问题 7:云原生架构对交易一致性如何应对?
91 0
|
11月前
|
存储 分布式计算 固态存储
「分布式架构」最终一致性:反熵
「分布式架构」最终一致性:反熵
|
11月前
|
存储 分布式计算 安全
「分布式架构」最终一致性:暗示的切换队列
「分布式架构」最终一致性:暗示的切换队列
|
11月前
|
数据库 内存技术
「分布式架构」一致性、因果性和最终性
「分布式架构」一致性、因果性和最终性
|
11月前
|
存储 弹性计算 缓存
「分布式架构」“一切都是分布式”说最终一致性
「分布式架构」“一切都是分布式”说最终一致性
|
11月前
|
存储 JSON 分布式计算
【数据库架构】Apache Couchdb 最终一致性
【数据库架构】Apache Couchdb 最终一致性
|
11月前
|
架构师 数据库 Windows
[分布式架构 ]分布式架构中可扩展性的交易一致性
[分布式架构 ]分布式架构中可扩展性的交易一致性
|
存储 数据采集 运维
一篇文章搞懂数据仓库:总线架构、一致性维度、一致性事实
一篇文章搞懂数据仓库:总线架构、一致性维度、一致性事实
一篇文章搞懂数据仓库:总线架构、一致性维度、一致性事实
|
消息中间件 存储 分布式数据库
从 GFS 失败的架构设计来看一致性的重要性(4)
从 GFS 失败的架构设计来看一致性的重要性(4)
181 0
从 GFS 失败的架构设计来看一致性的重要性(4)