一、分布式事务解决方案
今天，说两种分布式事务解决方案：
- Seata框架
- MQ分布式事务
下面分别详细说一下这两个方案。
二、Seata框架
Seata事务管理中有三个重要角色：
- TC(Transaction Coordinator)-事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。
- TM(Transaction Manager)-事务管理器：定义全局事务的范围，开启、提交、回滚全局事务。
- RM(Resource Manager)-资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
Seata提供了三种分布式事务管理模式：XA模式、AT模式、TCC模式。
2.1、XA模式
在XA模式下，共分为2个阶段。
-
RM一阶段的工作：
1.1. 注册分支事务到TC。
1.2. 执行分支事务SQL但不提交。
1.3. 报告执行状态到TC。
-
TC二阶段的工作：
TC检测各分支事务执行状态：
- 如果都成功，通知所有RM提交事务。
- 如果有失败，通知所有RM回滚事务。
-
RM二阶段的工作： 接收TC指令，提交或回滚事务。
XA模式采用了CP协议，需要互相等待各个分支事务提交，可以保证强一致性，性能差。
2.2、AT模式（推荐）
AT模式同样是分阶段提交的事务模型，不过弥补了XA模式中资源锁定周期过长的缺陷。
-
阶段一RM的工作：
- 注册分支事务。
记录undo-log(数据快照)。- 执行业务SQL并
提交。 - 报告事务状态。
-
阶段二提交时RM的工作：
- 删除undo-log即可。
-
阶段二回滚时RM的工作：
- 根据undo-log恢复数据到更新前。
AT模式采用了AP协议，分支事务之间各自提交，不需要互相等待。做到了高可用。
2.3、TCC模式
- Try：资源的检测和预留。
- Confirm: 完成资源操作业务。要求Try成功Confirm一定成功。
- Cancel：预留资源释放，可以理解为Try的反向操作。
TCC模式采用了AP协议，需要人工编码实现，性能好。
三、MQ分布式事务
如上图所示案例，通过向借呗借钱增加支付宝账户余额。
- 借呗系统进行资质审核。审核通过后，生成借款单持久化到MySQL中，并且发送MQ消息给支付宝系统。
- 支付宝系统接收到消息后，执行本地事务，增加账户余额。
- 如果审核不通过，后者借款单入库失败，则就不用发消息。所以发送MQ消息和入库要放在同个一事务中执行。
- 如果支付宝系统执行本地事务失败，只能手动处理。
- 优点：事务异步执行，性能比较高。
- 缺点：无法保证实时性。
- 使用场景：对实时性要求不高的系统。
