java分布式事务应放弃强一致，转向最终一致或业务补偿；推荐消息队列+本地事务表（入门）、tcc（资金类）、seata at（通用微服务）、xa（慎用，仅限小规模强一致场景）。
Java 中处理分布式事务，核心是放弃“强一致”的执念，转向“最终一致”或“业务级补偿”，同时根据场景权衡一致性、性能和开发成本。没有银弹方案，选型关键看业务容忍度和系统边界。
消息队列 + 本地事务表（推荐入门）
适合订单创建、通知推送、积分发放等对实时性要求不高、允许秒级延迟的场景。实现简单、解耦强、吞吐高。
- 在业务库中建一张 本地事务消息表，字段包括业务ID、消息内容、状态（待发送/已发送/失败）、重试次数
- 主业务逻辑与插入消息记录放在同一个
@Transactional本地事务里，保证“操作成功 → 消息必落库” - 单独起一个定时任务或监听线程，轮询状态为“待发送”的记录，调用 RocketMQ/Kafka 发送消息，并更新状态为“已发送”
- 下游服务消费消息后执行对应逻辑；若失败，靠重试+人工干预兜底
TCC 模式（资金类强管控场景）
适用于支付扣款、余额冻结、库存预占等对资金安全敏感、需精确控制资源生命周期的业务。它把事务逻辑下沉到业务层，不依赖数据库锁。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- Try 阶段：做资源检查和预留（如冻结用户 100 元，扣减可售库存 5 件），不真正扣减，记录日志便于回滚
- Confirm 阶段：真正执行（扣掉冻结金额、提交库存扣减），必须幂等，可重复执行无副作用
- Cancel 阶段：释放 Try 阶段占用（解冻余额、恢复库存），同样必须幂等
- 建议配合 Seata 使用，它能自动管理 TCC 接口调用顺序、超时和重试，减少手动编码错误
Seata AT 模式（通用微服务首选）
对业务代码侵入最小，适合大多数非金融类业务，比如电商下单+减库存+生成物流单。它通过代理数据源自动解析 SQL，生成前后镜像用于回滚。
- 引入
seata-spring-boot-starter，配置好 Seata Server 地址 - 在跨服务方法上加
@GlobalTransactional注解，框架自动开启全局事务上下文 - 各服务使用 Seata 代理的数据源，执行 SQL 时会自动记录 undo_log 表（用于二阶段回滚）
- 一阶段本地事务直接提交，二阶段异步清理或回滚；性能比传统 2PC 好，但不支持跨数据库类型（如 MySQL + Oracle）
XA 协议（慎用，仅限小规模强一致需求）
基于数据库原生 XA 支持（如 MySQL InnoDB、Oracle），由 Atomikos 或 JTA 容器协调，提供最接近单机事务的强一致性体验。
- 要求所有参与方都支持 XA，且必须使用 XA 数据源（
AtomikosDataSourceBean等） - 两阶段阻塞明显，协调者单点故障风险高，网络抖动易导致长事务和资源锁死
- 只建议用于低并发、核心账务等极少数不能容忍任何不一致的模块，日常微服务不推荐
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
