（1）两阶段提交方案/XA方案（2PC：Two-Phase Commit）

分布式事务的解决手段之一，就是两阶段提交协议（2PC：Two-Phase Commit）

那么到底什么是两阶段提交协议呢？

1994 年，X/Open 组织（即现在的 Open Group ）定义了分布式事务处理的DTP 模型。该模型包括这样几个角色：

应用程序（ AP ）：我们的微服务
事务管理器（ TM ）：全局事务管理者
资源管理器（ RM ）：一般是数据库
通信资源管理器（ CRM ）：是TM和RM间的通信中间件

执行流程：

两阶段提交，有一个事务管理器的概念，负责协调多个数据库（资源管理器）的事务，事务管理器先问问各个数据库你准备好了吗？如果每个数据库都回复ok，那么就正式提交事务，在各个数据库上执行操作；如果任何一个数据库回答不ok，那么就回滚事务。

缺点：

比较适合单块应用里，跨多个库的分布式事务，而且因为严重依赖于数据库层面来搞定复杂的事务，效率很低，绝对不适合高并发的场景。

总结：

这个方案，我们很少用，一般来说某个系统内部如果出现跨多个库的这么一个操作，是不合规的。现在微服务，一个大的系统分成几百个服务，几十个服务。一般来说，我们的规定和规范，是要求说每个服务只能操作自己对应的一个数据库。
如果你要操作别的服务对应的库，不允许直连别的服务的库，违反微服务架构的规范，你随便交叉胡乱访问，几百个服务的话，全体乱套，这样的一套服务是没法管理的，没法治理的，经常数据被别人改错，自己的库被别人写挂。
如果你要操作别人的服务的库，你必须是通过调用别的服务的接口来实现，绝对不允许你交叉访问别人的数据库！

（2）TCC方案

TCC的全程是：Try、Confirm、Cancel。

执行流程:

这个其实是用到了补偿的概念，分为了三个阶段：

1）Try阶段：这个阶段说的是对各个服务的资源做检测以及对资源进行锁定或者预留
2）Confirm阶段：这个阶段说的是在各个服务中执行实际的操作
3）Cancel阶段：如果任何一个服务的业务方法执行出错，那么这里就需要进行补偿，
   就是执行已经执行成功的业务逻辑的回滚操作。

举例解释：

比如说跨银行转账的时候，要涉及到两个银行的分布式事务，如果用TCC方案来实现，思路是这样的：
1）Try阶段：先把两个银行账户中的资金给它冻结住就不让操作了
2）Confirm阶段：执行实际的转账操作，B银行账户的资金扣减，C银行账户的资金增加
3）Cancel阶段：如果任何一个银行的操作执行失败，那么就需要回滚进行补偿，
  就是比如B银行账户如果已经扣减了，但是C银行账户资金增加失败了，那么就得把B银行账户资金给加回去

在这里插入图片描述

使用场景：

一般来说跟钱相关的，跟钱打交道的，支付、交易相关的场景，我们会用TCC，严格严格保证分布式事务要么全部成功，要么全部自动回滚，严格保证资金的正确性，在资金上出现问题。

比较适合的场景：这个就是除非你是真的一致性要求太高，是你系统中核心之核心的场景，比如常见的就是资金类的场景，那你可以用TCC方案了，自己编写大量的业务逻辑，自己判断一个事务中的各个环节是否ok，不ok就执行补偿/回滚代码。

而且最好是你的各个业务执行的时间都比较短。

但是说实话，一般尽量别这么搞，自己手写回滚逻辑，或者是补偿逻辑，实在太恶心了，那个业务代码很难维护。

缺点：

这种方案说实话几乎很少用人使用，我们用的也比较少，但是也有使用的场景。因为这个事务回滚实际上是严重依赖于你自己写代码来回滚和补偿了，会造成补偿代码巨大，非常之恶心。

（3）本地消息表

执行流程：

1）A系统在自己本地一个事务里操作同时，插入一条数据到消息表
2）接着A系统将这个消息发送到MQ中去
3）B系统接收到消息之后，在一个事务里，往自己本地消息表里插入一条数据，同时执行其他的业务操作，如果这个消息已经被处理过了，那么此时这个事务会回滚，这样保证不会重复处理消息
4）B系统执行成功之后，就会更新自己本地消息表的状态以及A系统消息表的状态
5）如果B系统处理失败了，那么就不会更新消息表状态，那么此时A系统会定时扫描自己的消息表，如果有没处理的消息，会再次发送到MQ中去，让B再次处理
6）这个方案保证了最终一致性，哪怕B事务失败了，但是A会不断重发消息，直到B那边成功为止

在这里插入图片描述

缺点：

这个方案说实话最大的问题就在于严重依赖于数据库的消息表来管理事务啥的？？？这个会导致如果是高并发场景咋办呢？咋扩展呢？所以一般确实很少用

（4）可靠消息最终一致性方案

这个的意思，就是干脆不要用本地的消息表了，直接基于MQ来实现事务。比如阿里的RocketMQ就支持消息事务。

大概的意思就是：
1）A系统先发送一个prepared消息到mq，如果这个prepared消息发送失败那么就直接取消操作别执行了
2）如果这个消息发送成功过了，那么接着执行本地事务，如果成功就告诉mq发送确认消息，如果失败就告诉mq回滚消息
3）如果发送了确认消息，那么此时B系统会接收到确认消息，然后执行本地的事务
4）mq会自动定时轮询所有prepared消息回调你的接口，问你，这个消息是不是本地事务处理失败了，所有没发送确认消息？那是继续重试还是回滚？一般来说这里你就可以查下数据库看之前本地事务是否执行，如果回滚了，那么这里也回滚吧。这个就是避免可能本地事务执行成功了，别确认消息发送失败了。
5）这个方案里，要是系统B的事务失败了咋办？重试咯，自动不断重试直到成功，如果实在是不行，要么就是针对重要的资金类业务进行回滚，比如B系统本地回滚后，想办法通知系统A也回滚；或者是发送报警由人工来手工回滚和补偿
在这里插入图片描述

（5）Seata AT模式

是seata框架中提供的一种模式,Atomic Transaction是基于两阶段提交协议的演变：

一阶段：执行本地事务，并返回执行结果
二阶段：
- 提交异步化，非常快速地完成。
- 回滚通过一阶段的回滚日志进行反向补偿。

详情参考: seata网址
一阶段

在一阶段，Seata 会拦截“业务 SQL”，首先解析 SQL 语义，找到“业务 SQL”要更新的业务数据，在业务数据被更新前，将其保存成“before image”，然后执行“业务 SQL”更新业务数据，在业务数据更新之后，再将其保存成“after image”，最后获取全局行锁，提交事务。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。
在这里插入图片描述
二阶段提交

二阶段如果是提交的话，因为“业务 SQL”在一阶段已经提交至数据库，所以 Seata 框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。

二阶段回滚：

二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的“业务 SQL”，还原业务数据。回滚方式便是用“before image”还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务数据”和 “after image”，如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。
在这里插入图片描述
不过因为有全局锁机制，所以可以降低出现脏写的概率。

AT 模式的一阶段、二阶段提交和回滚均由 Seata 框架自动生成，用户只需编写“业务 SQL”，便能轻松接入分布式事务，AT 模式是一种对业务无任何侵入的分布式事务解决方案。

详细架构和流程

Seata中的几个基本概念：

TC（Transaction Coordinator） - 事务协调者
维护全局和分支事务的状态，驱动全局事务提交或回滚（TM之间的协调者）。
TM（Transaction Manager） - 事务管理器
定义全局事务的范围：开始全局事务、提交或回滚全局事务。
RM（Resource Manager） - 资源管理器
管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

我们看下面的一个架构图
在这里插入图片描述

TM：业务模块中全局事务的开启者
- 向TC开启一个全局事务
- 调用其它微服务
RM：业务模块执行者中，包含RM部分，负责向TC汇报事务执行状态
- 执行本地事务
- 向TC注册分支事务，并提交本地事务执行结果
TM：结束对微服务的调用，通知TC，全局事务执行完毕，事务一阶段结束
TC：汇总各个分支事务执行结果，决定分布式事务是提交还是回滚；
TC 通知所有 RM 提交/回滚资源，事务二阶段结束。

一阶段：

TM开启全局事务，并向TC声明全局事务，包括全局事务XID信息
TM所在服务调用其它微服务
微服务，主要有RM来执行
- 查询before_image
- 执行本地事务
- 查询after_image
- 生成undo_log并写入数据库
- 向TC注册分支事务，告知事务执行结果
- 获取全局锁（阻止其它全局事务并发修改当前数据）
- 释放本地锁（不影响其它业务对数据的操作）
待所有业务执行完毕，事务发起者（TM）会尝试向TC提交全局事务

二阶段：

TC统计分支事务执行情况，根据结果判断下一步行为
- 分支都成功：通知分支事务，提交事务
- 有分支执行失败：通知执行成功的分支事务，“回滚数据”(补偿)
分支事务的RM
- 提交事务：直接清空before_image和after_image信息，释放全局锁
- 回滚事务：
  - 校验after_image，判断是否有脏写
  - 如果没有脏写，回滚数据到before_image，清除before_image和after_image
  - 如果有脏写，请求人工介入