目录一、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 JtaTransactionManager3. 优缺点✅优点：强一致性、编程简单，像本地事务一样使用 @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 套逻辑，开发成本高。