笔记 MIT6.824 Lecture 13: Spanner

最新推荐文章于 2023-03-12 21:58:25 发布

原创最新推荐文章于 2023-03-12 21:58:25 发布 · 448 阅读

0 ·

本内容遵循CC 4.0 BY-SA版权协议

6.824 同时被 2 个专栏收录

18 篇文章

订阅专栏

课堂笔记

8 篇文章

订阅专栏

前言

这个是在讨论了了Two Phase Commit(TPC)之后，Google的一个practice，应用了Paxos以及TPC来实现分布式事务，在一定程度上解决了TPC带来的速度问题

一、Spanner

1.1

系统overview
在这里插入图片描述
通过Paxos来管理replication，每个Shard一个paxos group，也就是说每个shard一个server，然后replicas是分布在不同的区域的

why通过paxos？

sharding可以满足更大的throughput
datacenters fail independently
clients can read local replica - fast
paxos 只需要majority - tolerate slow/distant replicas

1.2 Big challenges

想读local的数据，但是由于paxos(Raft)的关系，local数据不一定是最新的
Transaction involves in multiple shards
解决这些挑战的时候导致了读写使用了不同的策略

二、Read/Write Transactions

使用 two-phase commit (2pc) with Paxos-replicated participants
在这里插入图片描述
主要就是Two Phase commit and two phrase locking，一个Transaction会选择一个paxos作为Transaction coordinator

Locking 保证了Transaction
Two Phase Transaction 会有blocking，但是由于Paxos的特性，一旦server failure别的可以接上
虽然跨区的话速度比较慢，但是有很大的throughput

三、Read/Only Transactions

3.1 improve只读performance

大部分的操作其实都是read only的，所以我们很需要提高read only的速度。需要做到这一点

可以读取local replica而不是leader的shards
No locks, No two phase commit, No transaction manager

3.2 Correctness constraints on r/o transactions

Serializable
如果T1在T2前完成，那么T2就要看到T1的写操作，就是不能读stale data

但是不能读取最近修改过得values，因为最近修改的数据很有可能是某个transaction的temp数据，比如

T1:  Wx  Wy  C
T2:                 Wx  Wy  C
T3:             Rx             Ry

T3 的Rx就会读到旧的数据，二Ry则是读到新的数据

3.3 Snapshot isolation(SI)

Read/Write: TS = Commit time
Read/Only: TS = Start time

Example

x@10=9         x@20=8
y@10=11        y@20=12
    T1 @ 10:  Wx  Wy  C
    T2 @ 20:                 Wx  Wy  C
    T3 @ 15:             Rx             Ry

T3的Rx是@10版本的x，然后等Ry读的时候，读到的是@20的版本，由于Rx是@10的版本的，于是Ry给的也是@10的版本，这用通过让版本相同使得transaction满足Serializable
在这里插入图片描述

问题
如果T3没有看到T1的@10怎么办(因为T1并不是majority)？

方法
replica “safe time”。replica需要知道自己不是最新的，方法就是如果传过来的是读取15的数据，但是replica只有13的数据，miss了14的数据，replica就不会回复知道有14的数据过来为止

3.4 Time sync

What if the clocks are not synced:

对于Read/Write因为有two phase commit的机制，不会存在这个问题
对于Read/Only来说如果request的Timestamp大，那么等待paxos的跟新；如果request的Timestamp太小，会 miss recent writes，就是Not consist

Start value
TS = TT.now().latest
r/w - commit
r/o - start

Clock sync
在这里插入图片描述

其实就是因为时间会有出入，这样需要一个缓冲来保证这个出入带来的误差

Example

r/w T0 @  0: Wx1 C
r/w T1 @ 10:         Wx2 C
r/o T2 @  5:                   Rx?
(C for commit)

T2需要看到T1的Wx2的，但是时间的误差T2@5 < T1@10，所以需要time sync
Start rule:
Transaction TS = TT.now().latest
for r/o, at start time
for r/w, when commit begins
Commit wait, for r/w xaction:
Before commit, delay until TS < TS.now().earliest
Guarantees that TS has passed.

r/w T0 @  0: Wx1 C
                 |1-----------10| |11--------------20|
r/w T1 @ 10:         Wx2 P           C
                               |10--------12|
r/o T2 @ 12:                           Rx?
(P for prepare)

总的来说
Snapshot Isolatin 提供了Serializable r/o transaction
Synchronized 提供了external consistency