本地事务传播在多服务间失效，是因为spring的@transactional依赖同一jvm内aop代理和方法调用栈，而跨服务调用是远程http请求，服务b在独立进程开启新事务，与a完全隔离，无法共享事务上下文或回滚状态。
Java 中单服务内的事务靠 Spring 的 @Transactional 就能控制，但跨多个微服务调用时，本地事务无法自动传播——因为每个服务有独立数据库和事务管理器，Spring 的事务传播机制（如 REQUIRED、REQUIRES_NEW）只在同一个 JVM 内生效，不跨网络边界。
为什么本地事务传播在多服务间失效
事务传播是 Spring AOP 在代理对象上对方法调用做的拦截和增强，依赖于同一进程内的方法栈。当服务 A 调用服务 B 的 HTTP 接口时，实际是发起一次远程网络请求，服务 B 在自己进程中开启新事务，与服务 A 完全隔离。此时：
- 服务 A 的事务不会“传递”给服务 B；
- 服务 B 的异常不会回滚服务 A 的事务；
- 服务 A 也无法控制服务 B 使用哪种事务传播行为。
常见分布式事务解决方案及适用场景
要实现多服务间的事务一致性，需引入分布式事务模式。主流方案有：
- Seata AT 模式：基于两阶段提交（2PC），自动代理 JDBC 操作，记录 before/after image 实现回滚。适合 Java 技术栈统一、对强一致要求较高的业务（如订单+库存+支付）；
- 消息队列 + 本地消息表 / 事务消息（如 RocketMQ 事务消息）：服务 A 执行本地事务后发半消息，确认后再提交，B 消费消息执行操作。最终一致，性能好，适合异步解耦场景；
- TCC（Try-Confirm-Cancel）：业务层面拆分为三个接口（预留、确认、取消），侵入性强但灵活可控。适合资金类、高一致性要求且能改造业务逻辑的系统；
- Saga 模式：将长事务拆为一系列本地事务，失败时按反向顺序补偿。适合流程长、跨多个异构系统、允许短暂不一致的场景（如电商下单履约链路）。
Spring Cloud 下集成 Seata 的关键点
若选用 Seata，需注意以下实操细节：
- 所有参与服务都要引入
seata-spring-boot-starter，配置seata.tx-service-group指向同一事务分组； - 全局事务由发起方（如订单服务）加
@GlobalTransactional，而非@Transactional； - 被调用方（如库存服务）只需正常写业务逻辑，Seata 会通过 RPC 框架（如 Dubbo 或 OpenFeign + Seata 的适配器）透传 XID；
- 确保数据库连接池使用 Seata 包装的
DataSourceProxy，否则 SQL 不会被解析和拦截； - Feign 调用需添加
@GlobalTransaction的上下文传递支持（如通过拦截器注入 header 中的TX_XID）。
避免“伪分布式事务”的典型错误
开发中容易误以为加了多个 @Transactional 就实现了跨服务事务，结果是：
- 服务 A 提交成功，服务 B 报错，A 已无法回滚 → 数据不一致；
- 在 Feign Client 方法上加
@Transactional—— 这只是保护远程调用本身的重试或熔断，跟数据库事务无关； - 用
TransactionSynchronizationManager手动传播事务上下文 —— 仅限同 JVM，跨服务无效。
跨服务事务不是靠 Spring 传播机制解决的，而是靠分布式事务框架协调多个本地事务的生命周期。选型要结合一致性要求、性能瓶颈、团队技术储备和系统异构程度综合判断。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
