分布式事务有哪些常见的实现方案？-2PC

分布式事务：在分布式系统中一次操作需要由多个服务协同完成，这种由不同的服务之间通过网络协同完成的事务称为分布式事务

一、2PC：

2PC，两阶段提交，将事务的提交过程分为资源准备和资源提交两个阶段，并且由事务协调者来协调所有事务参与者，如果准备阶段所有事务参与者都预留资源成功，则进行第二阶段的资源提交，否则事务协调者回滚资源。

1、第一阶段：准备阶段

由事务协调者询问通知各个事务参与者，是否准备好了执行事务，具体流程图如下：

• ① 协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待答复
• ② 各参与者执行本地事务操作，将 undo 和 redo 信息记入事务日志中（但不提交事务）
• ③ 如参与者执行成功，给协调者反馈同意，否则反馈中止，表示事务不可以执行

2、第二阶段：提交阶段

协调者收到各个参与者的准备消息后，根据反馈情况通知各个参与者commit提交或者rollback回滚

（1）事务提交：

当第一阶段所有参与者都反馈同意时，协调者发起正式提交事务的请求，当所有参与者都回复同意时，则意味着完成事务，具体流程如下：

• ① 协调者节点向所有参与者节点发出正式提交的 commit 请求。
• ② 收到协调者的 commit 请求后，参与者正式执行事务提交操作，并释放在整个事务期间内占用的资源。
• ③ 参与者完成事务提交后，向协调者节点发送ACK消息。
• ④ 协调者节点收到所有参与者节点反馈的ACK消息后，完成事务。

所以，正常提交时，事务的完整流程图如下：

（2）事务回滚：

如果任意一个参与者节点在第一阶段返回的消息为中止，或者协调者节点在第一阶段的询问超时之前无法获取所有参与者节点的响应消息时，那么这个事务将会被回滚，具体流程如下：

• ① 协调者向所有参与者发出 rollback 回滚操作的请求
• ② 参与者利用阶段一写入的undo信息执行回滚，并释放在整个事务期间内占用的资源
• ③ 参与者在完成事务回滚之后，向协调者发送回滚完成的ACK消息
• ④ 协调者收到所有参与者反馈的ACK消息后，取消事务

所以，事务回滚时，完整流程图如下：

3、2PC的缺点：

二阶段提交确实能够提供原子性的操作，但是不幸的是，二阶段提交还是有几个缺点的：

（1）性能问题：执行过程中，所有参与节点都是事务阻塞性的，当参与者占有公共资源时，其他第三方节点访问公共资源就不得不处于阻塞状态，为了数据的一致性而牺牲了可用性，对性能影响较大，不适合高并发高性能场景

（2）可靠性问题：2PC非常依赖协调者，当协调者发生故障时，尤其是第二阶段，那么所有的参与者就会都处于锁定事务资源的状态中，而无法继续完成事务操作（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）

（3）数据一致性问题：在阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据部一致性的现象。

（4）二阶段无法解决的问题：协调者在发出 commit 消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了，那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。