笔记 MIT6.824 Lecture 13: Spanner

目录

• 前言
• 一、Spanner
• 二、Read/Write Transactions
• 三、Read/Only Transactions
• 总结

前言

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

---

一、Spanner

1.1

系统overview

通过Paxos来管理replication，每个Shard一个paxos group，也就是说每个shard一个server，然后replicas是分布在不同的区域的

why通过paxos？

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

1.2 Big challenges

1. 想读local的数据，但是由于paxos(Raft)的关系，local数据不一定是最新的
2. 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

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

---

三、Read/Only Transactions

3.1 improve只读performance

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

1. 可以读取local replica而不是leader的shards
2. 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

[e-mail]=9         [e-mail]=8
[e-mail]=11        [e-mail]=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:

1. 对于Read/Write因为有two phase commit的机制，不会存在这个问题
2. 对于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的，但是时间的误差[e-mail] < [e-mail]，所以需要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

---

总结

这是一个分布式系统同在不同区域上进行transaction的一个非常好的实践。读写操作与只读的操作分开使得可以再w/o的操作有速度的提升，从而提升整体速度；Paxos的引入减少了crash后lock带来的long waiting time