分布式系统：Lec 10 分布式事务

最新推荐文章于 2023-05-23 10:09:22 发布

颛顼子

最新推荐文章于 2023-05-23 10:09:22 发布

阅读量234

点赞数

文章标签： 6.824 分布式系统

本文链接：https://blog.csdn.net/hohomi77/article/details/102321824

版权

分布式事务

两种并发事务控制

悲观主义的。
- 先上锁，然后用。冲突意味着有人要等待。
乐观主义的。
- 先用，不上锁。Commit() 时检查读/写是否可序列化(serializable)。有冲突就要中止(abort)、重试。没有冲突的情况下，比加锁的方案更快。
  叫做：Optimistic Concurrency Control（乐观并发控制）

可序列化

可序列化 Serializable
- 执行结果可等价于一系列事务串行地执行。（能找到这样一种顺序，按这个顺序一个一个执行事务，产生的结果与实际执行结果一样。就说这个实际结果是可序列化的）
- 这里的执行结果指的是：记录的值和输出。

二阶段锁 2PL

这里介绍的不是普通的2PL，是一种“strong strict two-phase locking”，强严格二阶段锁。
要用的时候才上锁，第一次 执行get()、add()就包含对所操作的那条记录加锁的语义。
end_transaction()释放所有的锁。

例子疑问

Could 2PL ever forbid a correct (serializable) execution?
  yes; example:
    T1        T2
    get(x)  
              get(x)
              put(x,2)
    put(x,1) 
  locking would forbid this interleaving
  but the result (x=1) is serializable (same as T2;T1)

get(x)返回什么值没关系吗？如果T2; T1，那么T1的get(x)应该返回2。按照上图的顺序get(x)不会读到2。疑问？为什么notes说这里的交错执行是对的呢？
答案：因为没有print get(x)。虽然读了，但是没有输出就不管了。

二阶段提交

需要有一个事务协调者TC（transaction coordinator）
TC发RPC给A、B
A、B没有把修改数据立刻写到数据库，只是先存在另外的地方。
TC发PREPARE给A、B
A、B如果愿意commit，
- 就回答YES，进入"prepared"状态。
- 否则回答NO
如果2个都回答NO，TC就发送COMMIT给他们
否则发送ABORT
A/B 收到COMMIT就commit（把修改的数据写到真正的数据库）

要求

B如果回答了YES。然后，崩溃后重启。
B必须能完成commit，即便是经历了重启。

需要持久化的东西

subordinates
- 要记得YES（只要发过YES，就必须等待TC的决定。不能单方面撤回。）
- 自己做了commit 没有
- 修改的数据（尚未真正写到数据库的）
TC
- 要记得发过的COMMIT

Raft 和 2PC 的不同

Raft的目的是通过replicating来得到高可用
- 高可用：部分服务器挂了，仍然可以提供服务
- replicating：所有服务器做一样的事。
2PL 是不同服务器做不同的事，但是必须全部成功，或者全部撤销。
- 对高可用没有帮助
两者结合
- TC、A、B都不是一台服务器，TC/A/B分别都是多台服务器组成的raft cluster。既保证高可用（不怕单台服务器挂掉），又可保证原子性提交。Lab 4要用这个架构来实现shards迁移。

什么情况下worker会vote no？

Q: In two-phase commit, why would a worker send an abort message,
rather than a PREPARED message?
A: The reason we care most about is if the participant crashed and
rebooted after it did some of its work for the transaction but before
it received the prepare message; during the crash it will have lost
the record of tentative updates it made and locks it acquired, so it
cannot complete the transaction.
Another possibility (depending on how
the DB works) is if the worker detected a violated constraint on
the data (e.g. the transaction tried to write a record with a
duplicate key in a table that requires unique keys).
Another possibility is that the worker is involved in a deadlock, and
must abort to break the deadlock.