分布式事务的问题可以分为两部分：

• 并发控制 concurrency control
• 原子提交 atomic commit

分布式事务问题的产生场景：一份数据被分片存在多台服务器上，那么每次事务处理都涉及到了多台机器。

可序列化（并发控制）：

• 定义了事务执行的正确性
• 真正地并行执行事务，获得真正的并行速度提升。 如果事务涉及到的数据不在同一台机器上，那么可以同时在多台机器上读需要的数据。

原子提交：
处理在事务过程中服务器宕机的情况。如果事务执行过程中修改了部分值，然后机器宕机，需要能够具有故障恢复的能力。

一、并发控制

• 悲观并发控制。 冲突频繁比较适合，避免频繁abort事务。
• 乐观并发控制。事务最后的时候，再检查有无其它的事务干扰，如果有其它事务干扰，那么必须Abort当前事务。

2PL （Strongly 2PL）
规则：1. 使用任何数据之前，在执行任何数据的读写之前，先获取锁。

2. 事务必须持有任何已经获得的锁，直到事务提交或abort（这是严格2PL…）

规则2的例子：

不能在结束了对x的操作以后就立即释放锁，比如说：
t1： ① ④ t2： ② ③， 这个锁无用了，还是会导致事务交叉执行。

同时，2PL也无法解决死锁，简单例子如下：

二、原子提交

原子提交协议需要保证：事务的每一个部分都执行，或者任何一个部分都不执行。All-or-nothing
需要有一个计算机管理事务（事务协调者，Transaction Coordinator， TC）

2PC正常情况：

如果B在回复prepare yes之前崩溃： TC会发现B没有回复yes，也就不能commit，因为它需要等待所有参与者回复yes

同时，B如果发现自己故障，可以主动发起abort。 有一种情况，B故障，内存中数据丢失，所以再次接受prepare的时候，完全不知道参与了该次事务，因此直接发送No

如果B在发出prepare yes之后崩溃：
接下来极有可能发生的事情是，事务协调者从所有的参与者获得了Yes的回复，并将Commit消息发送给了A，所以A实际上会执行事务分包给它的那一部分，持久化存储结果，并释放锁。这样的话，为了确保All-or-Nothing原子性，我们需要确保B在故障恢复之后，仍然能完成事务分包给它的那一部分。在B故障的时候，不知道事务是否能Commit，因为它还没有收到Commit消息。但是B还是需要做好Commit的准备：
这要求参与者B在prepare时候必须持久化一些状态，比如说记住所有的修改和事务持有的锁 （这些其实都以log的形式存在）然后才会回复yes
这样，如果B在发送完prepare yes后就崩溃，那么恢复的时候可以查看自己的log。之后，B最终收到了commit，那么就可以完成它在事务中的那部分工作。

如果B在发出commit ok之后崩溃：此时B已经完成修改，数据以及持久化到磁盘上了，故障重启之后不需要做任何事情。

如果事务协调者在发送commit之前崩溃：那么没有一个参与者会commit事务

如果事务协调者在发送完一个或多个commit消息后崩溃：要重发，可以看Log来确定进展状况。
既然已经发送了，就不允许TC忘记相关的事务。这要求TC在发送任何commit之前，都必须先将事务信息写入持久化存储中。重启后可以看到哪些事务执行了一般，哪些事务commit，哪些事务abort，对于执行了一半的事务，事务协调者会向所有的参与者重发Commit消息或者Abort消息，以防在崩溃前没有向参与者发送这些消息。这也是为什么参与者需要准备好接收重复commit消息的原因。

TC发送prepare却没有收到所有回复？

• 重发
• 决定abort

发送commit却没有收到所有回复？

• block。 只能block，因为其他的参与者可能已经回复ok并提交事务

TC获得了所有的ack，此时TC可以删除Log中有关事务的信息；参与者发送ack之后也可以删除log（忘记这个事务…）
然后问题就来了，这个ack丢失了咋办。那此时TC会再次发送commit消息，参与者收到后发现自己不知道这个事务，但因为这是一个commit消息，说明自己一定是发送了ack后把log删除了，因此此时参与者会再次发送ack。

三、总结

2PC的性能

• 由于有多轮消息，非常慢
• 由于存在Block，很慢。

与Raft对比

Raft目标高可用，而2PC并不是高可用的。原因在于，Raft中的每台机器做一样的事情；而2PC中的机器在做不一样的事情（为了完成一个事务）

Raft+2PL实现高可用+ 分布式事务 原子提交？