分布式事务处理方案
1. 使用Seata框架解决
1.1 XA 事务
1.1.1 XA整体流程
- 第一阶段
- RM1开启XA事务-> 执行业务SQL -> 上报TC执行结果
- RM2开启XA事务-> 执行业务SQL -> 上报TC执行结果
- 第二阶段
- TC根据 RM上报结果通知RM一起提交/回滚XA事务
1.1.2 XA特点
- XA 模式必须要有数据库的支持，它开启的是XA事务，不是我们普通的本地事务。
-- 数据库1XA START 'xid1';UPDATE table1 SET col1=1 WHERE id=1;XA END 'xid1';XA PREPARE 'xid1';-- 数据库2XA START 'xid1';INSERT INTO table2 VALUES (2);XA END 'xid1';XA PREPARE 'xid1';-- 提交所有分支事务XA COMMIT 'xid1';
- XA模式是各分支事务执行完成业务SQL后会使用数据库锁一直锁定资源，直到收到事务协调者的消息后统一进行提交或回滚XA事务，所以是强一致性，并且全程锁定资源，性能很低。
1.2 AT模式
1.2.1 整体流程
-
第一阶段
-
RM1：开启本地事务 -> 业务SQL + undo_log -> 获取记录全局锁 -> 提交本地事务 -> 上报给TC执行结果
-
RM2：开启本地事务 -> 业务SQL + undo_log -> 获取记录全局锁 -> 提交本地事务 -> 上报给TC执行结果
-
-
第二阶段
- TC根据各分支执行结果选择事务提交或回滚
- 提交：提交全局事务，释放全局锁，异步删除undo_log日志
- 回滚：根据undo_log日志异步反向执行SQL进行反向补偿回滚操作，并删除undo_log记录。
- TC根据各分支执行结果选择事务提交或回滚
1.2.2 AT模式特点
- 在数据库本地事务隔离级别 读已提交（Read Committed） 或以上的基础上，Seata（AT 模式）的默认全局隔离级别是 读未提交（Read Uncommitted） 。
- 一阶段本地事务提交前，需要确保先拿到 全局锁 。拿不到 全局锁 ，不能提交本地事务。拿 全局锁 的尝试被限制在一定范围内，超出范围将放弃，并回滚本地事务，释放本地锁。
- 一阶段提交后会立即释放本地锁和连接资源，性能高。
1.3 TCC模式
1.3.1 TCC模式整体流程
- 一阶段：(Try):
- RM1：开启本地事务 -> 资源预留锁定SQL -> 提交本地事务。上报状态给TC。
- RM2：开启本地事务 -> 资源预留锁定SQL -> 提交本地事务。上报状态给TC。
- 二阶段：(Confirm/Cancel)::
- RM1：执行业务操作。上报事务状态给TC。
- RM2：回滚取消资源预留操作。上报事务状态给TC。
TCC 的Confirm /Cancel 操作在业务逻辑上是不允许返回失败的，如果因网络或其他故障失败会不断重试，直到成功，所以要求Confirm /Cancel 必须幂等。一般用在对中间状态有约束的业务中。try阶段设置中间状态锁定资源，确认阶段更新业务并设置为最终态，回滚阶段设置中间态为原始状态，其相关并发业务要考虑中间态的数据。
1.3.2 TCC模式特点
- 需要硬编码实现Try，Confirm，Cancel 三个操作，对业务系统有着非常大的入侵性。
- Try，Confirm，Cancel 三个操作都是独立的本地事务，不会长时间锁定资源，性能高。
1.3.3 TCC异常问题
- 空回滚：Try未执行，Cancel执行。原因：一个分支事务网络异常导致Try阶段未执行成功，故障恢复后，分布式事务进行回滚则会调用二阶段的Cancel方法，从而形成空回滚。
- 幂等：多次执行cancel() 或者 confirm()。原因：在重试过程中，实际重试成功了，但是由于网络原因，协调者没接收到重试成功的消息，再次去执行重试。
- 悬挂：Cancel在Try之前执行。原因：在 RPC 调用分支事务try时，此时网络发生拥堵，超过一定时间后协调者认为其执行出错了，通知其回滚该分布式事务，可能回滚完成后。Try 的 RPC 请求才到达参与者真正执行。
- 解决方案：设计一张事务状态记录表，在执行Try、confirm、Cancel 前对事务状态进行判断。seata已经帮助我们实现了。
1.4 SAGA模式
1.4.1 整体流程
Saga模式是SEATA提供的长事务解决方案，在Saga模式中，业务流程中每个参与者都提交本地事务，当出现某一个参与者失败则补偿前面已经成功的参与者，一阶段正向服务和二阶段补偿服务都由业务开发实现。
1.4.2 SAGA模式特点
- 一阶段提交本地事务，无锁，高性能
- 事件驱动架构，参与者可异步执行，高吞吐
- 补偿服务易于实现
- 不保证隔离性
1.5 Seata 各事务模式比较
| XA | AT | TCC | SAGA | |
|---|---|---|---|---|
| 一致性 | 强一致 | 弱一致 | 弱一致 | 最终一致性 |
| 隔离性 | 完全隔离 | 基于全局锁隔离 | 基于资源预留隔离 | 无隔离 |
| 代码侵入 | 无 | 无 | 有，编写三个接口 | 有，编写状态机和补偿业务 |
| 性能 | 差 | 好 | 非常好 | 非常好 |
| 场景 | 1.对一致性、隔离性有高要求的业务。2.需数据库支持XA协议。 | 1.基于关系型数据库的大多场景都可以。 | 对性能要求高的事务 | 1.业务流程长。2.参与者包含遗留系统，无法提供TCC三个接口 |
2. 使用消息队列解决
- 使用消息队列去解决分布式事务的特点就是事务参与者之间互相解耦，来实现事务的最终一致性。
- 使用消息队列就需要解决消息的可靠投递和消费。
- 由于事务参与者之间互相解耦，都以本地事务提交，所以没有隔离性。
2.1 使用RocketMQ事务消息实现
- 消息预投递：生产这者发送半事务消息到Broker，这个消息不会被立即消费，处于一个预提交状态。
- 本地事务执行：执行本地业务，提交本地数据库事务。
- 消息确认：提交/回滚消息，Broker将消息标记为已投递状态，消息可被正常消费。或者Broker回滚这个半事务消息，消息会被删除。
- 消息消费：其他事务参与者进行消息消费。
- 消费成功：一切OK
- 消费失败：重新消费，达到次数阈值后可选择人工参与，或者反向投递事务消息对上游业务进行回滚。
如果Broker未收到第二阶段消息确认，会回查消息事务状态来确定消息状态，这里需要实现 RocketMQ 的
TransactionListener接口，提供一个回查的接口。
2.2 使用其他MQ进行实现
其他MQ没有事务消息的特性，需实现借助本地消息表实现消息不丢失的问题。大致流程如下：
- 本地事务执行：执行本地业务SQL + 消息表SQL，提交本地数据库事务。
- 投递消息：异步扫描本地消息表获取未投递MQ的记录进行MQ投递。
- 消息消费：其他事务参与者进行消息消费。更新消息表记录状态。
由于为保证消息的可靠性引入本地消息表，并且定时异步扫描，所以在性能方面要比RocketMQ差，并且代码量会更大，设计更加复杂。