java多数据库分布式事务有三种主流方案：一是jta+xa实现强一致性，适用于金融等高一致低并发场景；二是seata at模式提供最终一致性，降低业务侵入性，适合微服务常规业务；三是本地消息表+可靠消息实现松耦合最终一致性，适用于大规模或遗留系统。
Java 中管理多数据库的分布式事务，核心是协调多个独立数据源上的操作，确保它们整体满足原子性——要么全提交，要么全回滚。这不能靠单个数据库的本地事务实现，必须引入跨资源的事务协调机制。
依赖 JTA + XA 协议做强一致性协调
这是最贴近传统 ACID 的方案，适用于对数据强一致要求高、并发压力不大的场景（如后台批处理、金融对账）。
- JTA 提供统一编程接口（如
UserTransaction），屏蔽底层差异；XA 是数据库需支持的标准协议，让每个数据库能参与两阶段提交（2PC） - 你需要为每个数据库配置
XADataSource（如 MySQL 的MysqlXADataSource），再交由 JTA 事务管理器（如 Atomikos 或 Narayana）统一调度 - Spring 中可通过
@Transactional声明式启用，但底层必须集成 JTA 实现，不能只靠 Spring JDBC 的单数据源事务管理器
用 Seata AT 模式降低业务侵入性
适合微服务架构下的常规业务，比如订单创建+库存扣减+积分变动，分布在不同数据库中。
- Seata 作为独立的事务协调器（TC），自动拦截 SQL 执行，生成前后镜像，在异常时反向回滚（无需手动写补偿逻辑）
- 业务代码基本保持原样，只需加注解和简单配置；各服务使用各自的数据库连接池，不强制要求数据库支持 XA
- 注意：AT 模式默认提供的是“最终一致性”，第一阶段提交后即释放本地锁，性能比 XA 高，但极端情况下存在短暂不一致窗口
基于本地消息表 + 可靠消息实现最终一致性
当系统规模大、对实时性要求不高，或部分服务无法改造（如遗留系统、第三方接口），推荐此松耦合方式。
- 在业务库中建一张本地消息表，把要发的消息和主业务操作放在同一个本地事务里写入（成功则消息一定发出）
- 单独起一个消息投递服务，轮询该表，将消息发到 RocketMQ/Kafka，并标记已发送；下游服务消费后执行对应逻辑
- 配合重试、死信、人工对账等手段兜底，保障最终数据一致，而不是强求瞬时一致
避免常见误区
不是所有跨库操作都该上分布式事务。很多场景其实可以重构设计来规避：
- 微服务规范中，一个服务原则上只操作自己的库；跨库更新应改为调用对方服务 API，而非直连其数据库
- 频繁使用的分布式事务会拖慢响应、加重数据库锁竞争；优先考虑拆分粒度、异步化、幂等设计
- 不要在 HTTP 调用链路中嵌套 JTA 事务——网络不可靠，超时、重试、服务重启都会导致事务状态不确定
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
