常见的7种分布式事务解决方案(2pc,3pc,Tcc,Seta、本地事务....)

一分布式事务

1.1 分布式事务

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

1.首先满足事务特性：ACID

2.而在分布式环境下，会涉及到多个数据库

总结：分布式事务处理的关键是：

1需要记录事务在任何节点所做的所有动作，事务进行所有的操作要么全部提交，要么全部回滚。目的是：保证分布式系统中的数据一致性。

二方案1:分布式2pc

2.1 分布式事务2PC流程

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

2.2 第一阶段：准备阶段

由事务协调者询问通知各个事务参与者，是否准备好了执行事务：

1.协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待答复

2.各参与者执行本地事务操作，将 undo 和 redo 信息记入事务日志中（但不提交事务）

3.如参与者执行成功，给协调者反馈同意，否则反馈中止，表示事务不可以执行。

流程如下：

2.3 第二阶段：提交阶段

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

2.3.1 如果正常提交阶段

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

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

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

2.3.2 如果异常回滚阶段

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

1.协调者向所有参与者发出 rollback 回滚操作的请求

2.参与者利用阶段一写入的undo信息执行回滚，并释放在整个事务期间内占用的资源

3. 参与者在完成事务回滚之后，向协调者发送回滚完成的ACK消息

4.协调者收到所有参与者反馈的ACK消息后，取消事务

事务回滚，流程如下：

2.4 分布式2pc的优点与缺点

优点: 尽量保证了数据的强一致，实现成本较低，在各大主流数据库都有自己实现，对于MySQL是从5.5开始支持。

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

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

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

3.数据不一致：两阶段提交协议虽然为分布式数据强一致性所设计，但仍然存在数据不一致性的可能，比如在第二阶段中，假设协调者发出了事务commit的通知，但是因为网络问题该通知仅被一部分参与者所收到并执行了commit操作，其余的参与者则因为没有收到通知一直处于阻塞状态，这时候就产生了数据的不一致性。

三方案2:分布式3pc

3.1 分布式事务3PC流程

3PC会分为3个阶段，CanCommit 准备阶段、PreCommit 预提交阶段、DoCommit 提交阶段，3pc是2pc提交协议的改进版本，3阶段提交有两个改动点：

1.在协调者和参与者中都引入了超时机制。因为加入了超时机制，这里的超时的机制作用于 预提交阶段 和 提交阶段。如果等待 预提交请求 超时，参与者直接回到准备阶段之前。提交阶段：如果等到提交请求超时，那参与者就会提交事务了。

2.在第1阶段和第2阶段中插入一个准备阶段，保证了在最后提交阶段之前各参与节点的状态都是一致的。

无论是2PC还是3PC都不能保证分布式系统中的数据100%一致。2PC和3PC都无法保证数据绝对的一致性，一般为了预防这种问题，可以添加一个报警，比如监控到事务异常的时候，通过脚本自动补偿差异的信息。

流图图如下：

3.2 第1阶段：准备阶段

协调者向参与者发送 canCommit 请求，参与者如果可以提交就返回Yes响应，否则返回No响应，具体流程如下：

（1）事务询问：协调者向所有参与者发出包含事务内容的 canCommit 请求，询问是否可以提交事务，并等待所有参与者答复。
（2）响应反馈：参与者收到 canCommit 请求后，如果认为可以执行事务操作，则反馈 yes 并进入预备状态，否则反馈 no。

3.3 第2阶段：预提交阶段

协调者根据参与者的反应情况来决定是否可以进行事务的 PreCommit 操作。根据响应情况，有以下两种可能：

3.3.1 执行事务

假如所有参与者均反馈 yes，协调者预执行事务，具体如下：

1.发送预提交请求：协调者向参与者发送 PreCommit 请求，并进入准备阶段
2.事务预提交：参与者接收到 PreCommit 请求后，会执行本地事务操作，并将 undo 和 redo 信息记录到事务日志中（但不提交事务）
3.响应反馈：如果参与者成功的执行了事务操作，则返回ACK响应，同时开始等待最终指令。

3.3.2 事务中断

假如有任何一个参与者向协调者发送了No响应，或者等待超时之后，协调者都没有接到参与者的响应，那么就执行事务的中断，流程如下：

1.发送中断请求：协调者向所有参与者发送 abort 请求。
2.中断事务：参与者收到来自协调者的 abort 请求之后（或超时之后，仍未收到协调者的请求），执行事务的中断。

3.响应阶段：参与者向协调者返回ACK的响应。

3.4 第3阶段：提交阶段

该阶段进行真正的事务提交，也可以分为以下两种情况：

3.4.1 执行事务

1.发送提交请求：协调接收到所有参与者发送的ACK响应，那么他将从预提交状态进入到提交状态，并向所有参与者发送 doCommit 请求
2.本地事务提交：参与者接收到doCommit请求之后，执行正式的事务提交，并在完成事务提交之后释放所有事务资源
3.响应反馈：事务提交完之后，向协调者发送ack响应。
4.完成事务：协调者接收到所有参与者的ack响应之后，完成事务。

3.4.2 事务中断

任何一个参与者反馈 no，或者等待超时后协调者尚无法收到所有参与者的反馈，即中断事务

1.发送中断请求：如果协调者处于工作状态，向所有参与者发出 abort 请求
2.事务回滚：参与者接收到abort请求之后，利用其在阶段二记录的undo信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。
3.反馈结果：参与者完成事务回滚之后，向协调者反馈ACK消息
4.中断事务：协调者接收到参与者反馈的ACK消息之后，执行事务的中断。

进入doCommit阶段后，无论协调者出现问题，或者协调者与参与者之间的网络出现问题，都会导致参与者无法接收到协调者发出的 doCommit 请求或 abort 请求。此时，参与者都会在等待超时之后，继续执行事务提交。这其实基于概率来决定的，当进入第三阶段时，说明第一阶段收到所有参与者的CanCommit响应都是Yes，意味着大家都同意修改了，并且第二阶段所有的参与者对协调者的PreCommit请求也都是同意的。所以，一句话概括就是，当进入第三阶段时，由于网络超时等原因，虽然参与者没有收到commit或者abort响应，但是他有理由相信：成功提交的几率很大。