笔记 MIT6.824 Lecture 12: Distributed Transactions

前言

这是Lecture12的上课记录，分布式事务，主要讲了两个话题，分别是Concurrency control以及atomic。重点是理解two phase commit，这个后面介绍的很多事务读写处理都有用到

一、问题

有大量的数据，需要分库，并且需要Transaction

Transaction的特性 - ACID
Atomic 原子性
Consistent
Isolated - Serializable
Durable

Serializable if some order execution of transactions that yields some result 也就是特定的transaction序列在任何时候都产同一个特定的结果。比如说Transaction 1 跟 Transaction 2，会有两结果T1T2->result or T2T1->result, 如果在T2执行了一般然后执行T1再完成T2的后面一半就会产生不一样的结果，这就不是Serializable。

Serializable的特性也保证了两个不相关的Transaction可以并行运行，这个特性对于programmer来说是非常有好的，减少了很多应用层处理数据的逻辑

---

二、Concurrency control

1. Pessimistic
2. Optimistic

Pessimistic - Two-Phase Locking
Two-Phase Locking定义

a transaction must acqure a record’s lock before using it
a transaction mush hold its locks until after commit or abort

Acquire lock before using record
Hold until done

---

三、Distributed Transaction VS failures

Two-phase commit

TC - Transaction coordinator

2 Phase commit

Two scenarios

• Crash before sending the Yes
  把信息先缓存起来，如果没有后续commit则删掉即可

• Crash after sending the Yes
  所有servers在发送Yes前，都把数据写到log里面，然后没有crash的server可以recover

• 在发送YES前，如果没有得到response，abort the transaction
  在发送YES后，如果没有得到response，DB server需要等待直到transaction coordinator made the decision

其实在commit之前保证有log就可以了

为什么两个servers可以做Transaction?
主要是因为transaction is made by a single entity, 不是DB server决定是否commit

什么时候Transaction Coordinator可以情况可以清空log？
收到full commit为止

---

四、关于Two-phase commit

问题

1. slow: multiple rounds of messages
2. slow: disk writes
3. TC crash can cause indefinite blocking, with locks held Thus usually used only in a single small domain

Raft and two-phase commit solve different problems
Use Raft to get high availability by replicating
Use 2PC when each participant does something different

---

总结

介绍了普遍使用的分布式事务的做法，也就是Two Phase Commit，由于使用了悲观锁，导致性能有问题，但是可以通过别的方法提升一部分性能，比如之后谈到的spanner