目录
背景
1 XA规范分布式事物方案
1.1 俩阶段提交（2PC）
1.2 三阶段提交（3PC）
2 补偿事务（TCC）
3 可靠消息最终一致性方案
4 可靠消息最终一致性方案
5 SAGA事物
6 Seata AT 模式
背景
分布式事务出现的原因:
1 在微服务环境下，服务与服务之间一般是采用RPC远程调用的，每个服务都有自己独立的数据库，既自己的本地事务。
2 在一个项目中如果采用多个数据源，也会出现分布式事务的现象。
由于数据库分库分表和应用SOA化（微服务）的出现，为了保证不同数据库的数据一致性，分布式事物的概念也就诞生了，主要有以下几种：
1 XA规范分布式事物方案
- 场景：不适用于并发量大的业务场景，适用于单系统多数据源
- 开源的框架：spring-boot-starter-jta-atomikos,seata框架
1.1 俩阶段提交（2PC）
- 基本流程
- 缺点
| 不足 | 原因 |
| 数据不一致的问题 | 1 TM通知RM(A)，RM(B)提交 2 RM(A）成功提交，RM（B)由于网络抖动 3 没有接收到请求，导致无法提交，且占用了资源 |
| 单点故障风险 | RM出现故障，参与者就无法commit。资源会阻塞。 |
| 性能问题 | 参与者在事务提交阶段处于同步阻塞状态，占用系统资源 |
1.2 三阶段提交（3PC）
- 基本流程
- 相对于2PC的改进:参与者在一定时间内未收到协调者的commit请求，会自动提交事务，不会一致阻塞等待
- 不足：还是会出现数据不一致（见2PC的数据不一致的不足）
2 补偿事务（TCC）
- 场景：对金额要求性很高的业务场景，银行核心主机的账务系统，不容半点差池。
- 开源的框架：tcc-transaction框架，himly框架，ByteTCC框架，seata框架
- 基本流程
- 其实就是针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作
| 名词 | 含义 | 用法场景例子（订单的支付） |
| Try | 这个阶段对各个服务的资源检测以及对资源进行锁定或者预留【锁定资源】 | 先置一个中间状态“UPDATING”，而不是直接设置“支付成功”状态 |
| Confirm | 执行真正的业务操作，不作任何业务检查，只使用Try阶段预留的业务资源【要求具备幂等设计】 | 将订单的中间状态变更为PAYED-支付成功 |
| Cancel | 如果任何一个服务的业务方法执行出错， | 将订单的状态设置为“CANCELED” |
PS:分布式事务TCC模式的空回滚和业务悬挂问题 - 腾讯云开发者社区-腾讯云
3 可靠消息最终一致性方案
- 场景：对数据非强一致性要求，可接受短暂的延迟，如申请退款后，可接受“你的余额将再2小时内返回”。
- 实现：基于本地消息表服务（自研），基于支持分布式事务的消息中间件（RocketMQ）
- 基本流程
- 基于本地消息表服务的脑图
4 可靠消息最终一致性方案
- 场景：适用于一些最终一致性时间敏感度低的业务。
- 实现：需要结合自身的业务去实现【其实就是重试的JOB】
5 SAGA事物
- 场景：订单履约成功后，通知仓储系统配货，配货成功后，需要通知物流系统。类似于工作流的方式。
- 事物思想：将一个长的分布式事务，拆分为一连串的每个服务的本地事务，然后每个服务对每个接口提供两个接口。一个是业务接口，一个是回滚的补偿接口，正常情况下就是依次的进行调用。
- 实现：seta框架
- 基本流程
- 处理事务一致性方式
- 向前恢复策略：不断重试的方式保证事务完成
- 向后恢复策略：后者通过子事务的补偿事务，逐一回滚的方式让事务标记失败
6 Seata AT 模式
- 概念：AT模式是一种无侵入的分布式事务解决方案，在 AT 模式下，用户只需关注自己的“业务 SQL”，用户的 “业务 SQL” 作为一阶段，Seata 框架会自动生成事务的二阶段提交和回滚操作。
- 机制：一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。
二阶段：提交异步化，非常快速地完成。回滚通过一阶段的回滚日志进行反向补偿。
- 整体的概要流程图：
具体的流程可参照 seata的AT模式_最爱奶油花生的博客-CSDN博客_seata的at模式
作者：老喵
