Apache Seata多数据源场景下本地事务失效问题解析

背景概述

在使用Apache Seata分布式事务框架时，开发者常会遇到多数据源配置与本地事务管理的兼容性问题。特别是在结合MyBatis-Plus多数据源场景下，当配置多个DataSourceTransactionManager时，若未正确处理Bean命名和代理机制，会导致@Transactional注解失效，出现事务自动提交现象。

问题现象

典型表现为：

1. 配置多个数据源时，每个数据源都声明了同名的事务管理器Bean（dataSourceTransactionManager）
2. 启用了Seata代理后，本地事务注解失效，SQL语句立即提交
3. 排除Seata依赖或使用@GlobalTransactional时事务恢复正常
4. 修改事务管理器Bean名称并添加@Primary注解后可恢复正常

核心原理

Seata通过DataSourceProxy对原生数据源进行包装，实现分布式事务的拦截和管理。在多数据源环境下：

1. Bean命名冲突：Spring容器中同名的Bean会相互覆盖，导致实际生效的事务管理器不确定
2. 代理优先级：Seata的代理机制会覆盖部分本地事务管理器的功能
3. 事务传播机制：当存在多个候选事务管理器时，Spring默认需要明确的@Primary指定

解决方案

方案一：规范Bean命名

// 主数据源配置
@Bean("masterTransactionManager") 
public DataSourceTransactionManager masterTxManager() {
    return new DataSourceTransactionManager(masterDataSource());
}

// 从数据源配置  
@Bean("slaveTransactionManager")
public DataSourceTransactionManager slaveTxManager() {
    return new DataSourceTransactionManager(slaveDataSource());
}

方案二：显式指定Primary

@Bean("dataSourceTransactionManager")
@Primary
public DataSourceTransactionManager primaryTxManager() {
    return new DataSourceTransactionManager(primaryDataSource());
}

方案三：手动代理控制

对于Seata 2.0+版本，建议关闭自动代理：

seata.enable-auto-data-source-proxy=false

然后手动创建代理数据源：

@Bean
public DataSource dataSource() {
    return new DataSourceProxy(originalDataSource());
}

最佳实践建议

1. 多数据源环境下，每个事务管理器应使用唯一Bean名称
2. 明确指定主事务管理器（通过@Primary）
3. 在Seata环境中，建议采用手动代理方式
4. 事务管理器应与对应数据源保持严格对应关系
5. 测试阶段应验证事务的传播行为和回滚效果

深度思考

这种现象本质上是Spring事务管理机制与Seata代理层的交互问题。在分布式事务框架中，本地事务管理器实际上需要让渡部分控制权给全局事务协调器。开发者需要理解这种分层设计，才能正确配置多层级的事务管理组件。

对于复杂场景，建议采用分层配置：

1. 基础层：定义原始数据源
2. 代理层：添加Seata的DataSourceProxy
3. 事务层：配置对应的事务管理器
4. 应用层：通过注解控制事务边界

这种清晰的层次划分可以避免大多数代理冲突问题，同时保持配置的可维护性。