Spanner

多处读取，解决读旧数据的问题

可能要操作不同的paxos组，需要分布式事务

Spanner比较有意思的点主要是：

快照隔离机制，该机制可以让只读型事务不经过2PC
TrueTime机制，在多地不同机器中，时钟不太可能完全同步，利用该机制就可以解决时钟不同步带来的问题。

外部一致性

Spanner引入了外部一致性的概念。指的就是在外部观测到一个事务，这个事务需要能看到在它开始之前（用真实时间瞄定）的所有已提交的事务所做的修改。

本质上其实就是一种 线性一致性。

分布式事务实现

Spanner把事务分为：

R/W：读写型事务

R/O：只读型事务

读写事务

二阶段提交会因为TC挂了卡死掉

Spanner使用paxos复制TC解决这个问题

读写型事务开销较大，如果明确都是读请求，应该转而实现只读型事务。

总结：读写事务还是用了2PC，只不过使用paxos算法复制了TC（事务协调者）。

只读型事务

只读型事务不用经过2PC，而且可以直接找最近的节点读取。

2个正确性保证

有顺序 serializable
外部一致性线性一致性

Snapshot Isolation 快照隔离

假设所有节点时钟同步

时间戳

我们给每个事务都标记上时间戳TIMESTAMP：

读写型事务：

把提交时间作为时间戳

TS = COMMIT TIME
只读型事务：

把只读型事务开始的时间作为时间戳

TS = START TIME

只读型事务读取快照规则

每个读写事务提交后，都会保存该事务的快照，快照会附带最后一次事务的TS。

而只读型事务，只需要去该只读事务TS前最近的一个快照去读取数据就好了。

上图中，

T1: 写x 写y 然后提交，提交时间是10，作为TS，生成快照@10
T2: 写x 写y 然后提交，提交时间是20，作为TS，生成快照@20
T3: 读x 读y，开始时间是15，作为TS

由于上文提到的规则，T3读取的是快照@10的值，得到x = 9， y = 11

how does it not absolutely brow up the storage? 这样做不会爆空间吗？

spanner肯定会丢掉过时的版本的snapshot，论文中没有详细提到。

其实就是，当TS < 15的只读型事务结束时，@15之前的快照版本就不需要了。只需要记录仍然还在执行的事务执行前的快照就好了（不会太多）

PS: paper中说可以取得这个数据昨天的版本，看起来应该保存的版本会更久一些。

如果读取数据的节点是少数派怎么办？ SAFE TIME机制

只读型事务可以找最近的节点读取，但是paxos也只是多数复制，如果客户端读取的节点是少数派，并没有更新到最新的数据怎么办？

对此Spanner引入了SAFE TIME机制。Paxos ledear上的log会记录时间戳并且严格按照时间戳顺序发给replica，同时replica会记录从leader拿到的最后的log的时间戳。

当只读事务的时间戳>最新日志的时间戳时，会延迟直到收到更新的日志后再发送。

对于上面那个图的例子来说，就是如果要执行TS为15的只读型事务，就必须等到收到时间戳>15的log才可以进行。由于paxos按照时间戳发送，这时候肯定已经更新了时间15之前的所有数据了。

这个机制可能稍稍延迟只读事务。

各个节点时钟不同步怎么办？What if clocks aren’t synced？ Spanner’s True Time Interval

时钟不同步的后果

只读型事务取得的时间偏快

这种情况下，T2开始之前，T1就提交了，由外部一致性，T2一定要能看到T1的修改。

但是由于T2和T3是并发执行的，所以T2可以看到T3的修改，也可以不看到，都符合外部一致性。

所以如果只读型事务的TS取得偏快，如图中这个情况，T2会读取@14的快照，无非就是多等待一段时间（SAFT TIME机制），还是满足外部一致性的。

只读型事务取得的时间偏慢

这时候，T2会读不到T1的修改内容。**由于T2开始的真实时间是晚于T1提交的，由外部一致性，T2必须看到T1的修改。**这时候由于节点时钟没办法完全同步，就会造成不符合外部一致性的问题。

TrueTime Interval

为了解决上述问题，Spanner引入了TrueTime机制。

Spanner利用GPS和原子钟（只是手段），保证了节点获得的时间误差在一个范围内。

True Time Interval: 反应正确时间的区间

(EARLIST, LATEST)

然后，spanner使用两条规则保证外部一致性：

时间戳定义

使用TrueTime的最晚值作为时间戳。

TS = TT.now().latest

对于读写型事务，时间戳依然为事务提交的结束时间的TS；对于只读型事务，时间戳依然为事务开始时间的TS。

等待提交机制

对于读写型事务，按照上面所说的规则，时间戳依然为事务提交的结束时间的TS，此外，要求等待直到真实时间一定已经超过了改事务的时间戳以后，事务才实际提交。

即：

wait until TT.now().earliest > CommitTS

该机制能保证，当事务提交以后再获得的TrueTime，即使有误差，也不可能小于该事务的时间戳。 也就是说，如果紧接着就开启一个只读型事务，该只读型事务的TS，即使有误差，也一定是>前面那个事务的TS，一定能看到前一个事务的修改。这个机制保证了事务的外部一致性。

保证如果真实时间上，开启的时间在该读写型事务提交之后的只读型事务，一定能够看到该读写型事务的修改。

比如下面这个例子：

事务T1选择了10为时间戳，但是它实际的提交需要等到保证真实时间绝对超过了10以后，再时间提交。这样，真实时间在10之后开启的只读型事务T3，取到的时间戳就一定>10, 可以正确读取到T1所做的修改。

Spanner学习笔记相关推荐

Reliable Cloud Infrastructure: Design and Process学习笔记
最后更新2022/03/16 忘记更新对应的学习笔记,补上.这一科有9节,加上0章简介简介 google cloud的好多功能有点相似,这科内容是介绍应该选什么产品,怎么选择,怎么规划,怎么设计等等 ...
PyTorch 学习笔记（六）：PyTorch hook 和关于 PyTorch backward 过程的理解 call
您的位置首页 PyTorch 学习笔记系列 PyTorch 学习笔记(六):PyTorch hook 和关于 PyTorch backward 过程的理解发布: 2017年8月4日 7,195阅读 ...
容器云原生DevOps学习笔记——第三期：从零搭建CI/CD系统标准化交付流程
暑期实习期间,所在的技术中台-效能研发团队规划设计并结合公司开源协同实现符合DevOps理念的研发工具平台,实现研发过程自动化.标准化: 实习期间对DevOps的理解一直懵懵懂懂,最近观看了阿里专家带 ...
容器云原生DevOps学习笔记——第二期：如何快速高质量的应用容器化迁移
暑期实习期间,所在的技术中台-效能研发团队规划设计并结合公司开源协同实现符合DevOps理念的研发工具平台,实现研发过程自动化.标准化: 实习期间对DevOps的理解一直懵懵懂懂,最近观看了阿里专家带 ...
2020年Yann Lecun深度学习笔记（下）
2020年Yann Lecun深度学习笔记(下)
2020年Yann Lecun深度学习笔记（上）
2020年Yann Lecun深度学习笔记(上)
知识图谱学习笔记（1）
知识图谱学习笔记第一部分,包含RDF介绍,以及Jena RDF API使用知识图谱的基石:RDF RDF(Resource Description Framework),即资源描述框架,其本质是一个 ...
计算机基础知识第十讲,计算机文化基础（第十讲）学习笔记
计算机文化基础(第十讲)学习笔记采样和量化PictureElement Pixel(像素)(链接: 采样的实质就是要用多少点(这个点我们叫像素)来描述一张图像,比如,一幅420x570的图像,就表示 ...
Go 学习推荐 —（Go by example 中文版、Go 构建 Web 应用、Go 学习笔记、Golang常见错误、Go 语言四十二章经、Go 语言高级编程）
Go by example 中文版 Go 构建 Web 应用 Go 学习笔记:无痕 Go 标准库中文文档 Golang开发新手常犯的50个错误 50 Shades of Go: Traps, Gotc ...

Spanner学习笔记