Java 分布式事务详解：4 大类主流方案（原理、执行流程、优缺点、使用场景、区别对比）
目录
一、2PC 两阶段提交（数据库层面，XA 规范）
1. 原理 & 执行流程
2. Java 落地实现
3. 优缺点
4. 适用场景
二、TCC（Try-Confirm-Cancel，侵入代码型柔性事务）
1. 三段式执行流程（业务代码手动编码，无锁）
2. Java 落地
3. 优缺点
4. 适用场景
三、可靠消息最终一致性（本地消息表 / MQ 事务，最常用）
方案分两种：本地消息表、MQ 事务消息（RocketMQ、RabbitMQ 事务）
1. 本地消息表流程（通用，所有 MQ 都能用）
2. RocketMQ 事务消息（原生封装，省去本地消息表）
3. Java 落地
4. 优缺点
5. 适用场景
四、SAGA（长事务、大流程事务，Seata-SAGA）
1. 执行流程
2. Java 落地
3. 优缺点
4. 适用场景
四大方案核心区别对比表
Java 开发选型口诀
补充：Seata 框架（Java 分布式事务一站式）
Seata AT（最常用，无代码侵入的改进 2PC）
分布式事务：跨多个数据库 / 微服务的数据操作，要么全部成功、要么全部回滚，CAP 理论下不存在完美方案，工程分：**2PC、TCC、SAGA、本地消息表 / 可靠消息最终一致性（MQ 事务）** 四大主流，Java 开发最常用后三种。
前置：本地事务是单库 ACID；分布式跨库 / 跨服务，无法依赖数据库原生事务。
一、2PC 两阶段提交（数据库层面，XA 规范）
1. 原理 & 执行流程
2PC =准备阶段 (Prepare) + 提交阶段 (Commit)，遵循 XA 规范，由事务协调者 TM+ ** 多个资源 RM (各个数据库)** 组成。
- 阶段 1：Prepare（预提交）TM 向所有参与的 RM 发送预提交请求； 各 RM 执行 SQL、锁定资源、写入 undo/redo 日志，但不真正提交事务，返回 ok / 失败； 任意一个 RM 返回失败，进入全局回滚。
- 阶段 2：Commit/Rollback（确认）
- 全部 Prepare 成功：TM 下发 commit，各 RM 正式提交事务、释放锁；
- 任一 Prepare 失败：TM 下发 rollback，所有 RM 回滚数据、释放锁。
2. Java 落地实现
- JDBC XA：
XADataSource、XAResource（MySQL、Oracle 支持 XA） - 框架：Atomikos、Bitronix、Narayana（JTA 规范实现），Spring JtaTransactionManager
3. 优缺点
✅优点：强一致性、编程简单，像本地事务一样使用 @Transactional ❌缺点：
- 性能极差：Prepare 阶段占用行锁 / 表锁，长事务阻塞其他请求；
- 协调者宕机阻塞：TM 宕机，RM 一直持有锁，死锁风险；
- MySQL 5.7 XA 有 bug，生产极少用。
4. 适用场景
短事务、少数据源（≤3 个库）、低并发，传统老旧项目，微服务基本弃用。
二、TCC（Try-Confirm-Cancel，侵入代码型柔性事务）
1. 三段式执行流程（业务代码手动编码，无锁）
TCC 把每个微服务拆成Try、Confirm、Cancel三个接口，由事务协调器（Seata-TCC、ByteTCC）调度。
- Try：预留资源（检查 + 锁定资源，不正式扣减 / 新增）冻结资源：比如库存冻结、余额冻结，数据库执行冻结 SQL，业务数据状态变为「待确认」； 全部服务 Try 成功 → 进入 Confirm；任一失败 → 全部 Cancel。
- Confirm：确认提交（正式执行业务）所有服务 Confirm，把冻结资源实际扣减，永久落库；Confirm 必须幂等（防止重复调用）。
- Cancel：取消回滚（释放预留资源）释放冻结资源，恢复数据；Cancel 也要幂等，避免重复回滚。
核心：Try 占资源、Confirm 确认、Cancel 补偿回滚，无数据库锁，靠业务状态控制
2. Java 落地
- 框架：Seata TCC、ByteTCC、Hmily
- 编码：每个分布式接口必须实现 3 个方法，侵入业务代码。
3. 优缺点
✅优点：性能高、无长事务锁、一致性可控、无中间件依赖； ❌缺点：代码侵入极强，开发量大，每个接口写 3 套逻辑，开发成本高。