多数据源事务：JTA vs 本地消息表，但已有分布式事务。

多数据源事务几乎是每个系统从单体走向服务化时都会踩的坑。一个业务操作要同时写订单库和库存库，或者既写 MySQL 又写 MongoDB，异常一发生，数据就不一致。社区里最常被拿来做对比的两套方案，是 JTA/XA 和本地消息表。但很多团队其实已经引入了 Seata、TCC、Saga 或者事务消息，于是问题变成了：既然已有分布式事务，还要不要在这两者之间纠结？

先厘清问题：多数据源不等于跨服务

多数据源至少分两种。一种是同一个应用内配置了多个数据源，比如主库和日志库、MySQL 和 MongoDB；另一种是业务已经拆成多个服务，每个服务有自己的库。前者可以用框架层事务协调，后者本质上是分布式事务。JTA 和本地消息表都能处理一部分场景，但边界不同。JTA 更偏强一致，本地消息表更偏最终一致。如果已有分布式事务组件，首先要判断它覆盖的是哪种场景，而不是直接换方案。

JTA：强一致的“重武器”

JTA 依赖 XA 协议，通过两阶段提交保证多个资源管理器要么都提交，要么都回滚。优点很直接：编程模型接近本地事务，一致性语义强，适合金融、账务等不能接受中间态的短事务。但代价也很明显。XA 事务持锁时间长，性能衰减随数据源数量放大；数据库、消息队列、NoSQL 对 XA 的支持参差不齐；运维排查链路复杂，云原生环境下还容易遇到连接池和超时问题。如果团队已经上了 Seata AT，JTA 往往不再是首选，因为 Seata 在应用层做了类似两阶段的效果，对业务侵入更小，生态也更贴近微服务。

本地消息表：最终一致的“工程化选择”

本地消息表的核心思路是：业务数据和消息记录放在同一个本地事务里提交，然后异步投递消息，失败就重试，消费端做幂等。它不要求数据库支持 XA，性能好，链路可控，适合订单创建后发通知、积分发放、日志同步这类允许短暂不一致的场景。缺点是需要额外维护消息表、重试策略、死信处理和对账补偿，一致性是延迟的，不是瞬时的。如果已有可靠消息队列的事务消息能力，本地消息表的一部分职责可以被替代，但它仍然适合跨中间件、跨存储的异构场景。

已有分布式事务，选型逻辑要变

如果项目里已经有 Seata、TCC、Saga 或事务消息，那么“JTA vs 本地消息表”就不应该再被当成二选一。更合理的问法是：现有分布式事务能不能覆盖当前多数据源？能覆盖，就不要为了技术偏好再引入 JTA 或消息表；覆盖不了，再考虑用本地消息表做异步补偿，或者用 JTA 兜底强一致。比如核心转账走 Seata AT，异步通知走本地消息表；跨库报表走消息表，强一致扣减走 TCC。关键是避免同一套链路里出现多个事务协调器，否则排查问题会非常痛苦。

务实的决策顺序

第一，能通过业务拆分变成单库单服务，就不要做多数据源事务。第二，已有分布式事务能覆盖，优先复用，别重复造轮子。第三，允许最终一致、链路异步，优先本地消息表或事务消息。第四，只有强一致、短事务、数据库同构且并发不高的场景，才考虑 JTA/XA。最后，无论选哪种，幂等、重试、对账、告警都是绕不开的配套工程。

多数据源事务没有银弹。JTA 和本地消息表代表两种不同的取舍：强一致与高性能、即时与最终一致。已有分布式事务不是终点，而是选型的起点。先看业务一致性要求，再看现有组件边界，最后才决定要不要引入新方案。能少一个协调器，就少一个深夜告警的理由。