当前位置：首页 > news >正文

Seata AT模式代理数据源失效剖析：为何RM不写undo_log而global_table却有记录？

news 2026/4/16 21:15:16

1. Seata AT模式核心机制解析

先来聊聊Seata AT模式的基本工作原理。AT模式全称Auto Transaction，是Seata最常用的分布式事务解决方案。它的核心思想是通过对业务SQL的解析，自动生成反向回滚日志（undo_log），实现事务的自动回滚。

在实际运行中，AT模式会经历几个关键阶段：

第一阶段：业务SQL执行时，RM（Resource Manager）会先查询数据的前镜像（before image）并存入undo_log
第二阶段：执行业务SQL修改数据
第三阶段：生成后镜像（after image）
当需要回滚时，根据undo_log中的前镜像数据恢复原始状态

这里有个关键点：所有数据修改操作都必须经过Seata的DataSourceProxy代理。只有通过这个代理，Seata才能拦截SQL并生成undo_log。如果代理没生效，就会出现文章开头描述的现象——global_table有记录（说明事务已开启），但undo_log表空空如也。

2. 代理数据源失效的典型表现

我在实际项目中遇到过好几次代理失效的情况，症状都非常相似：

事务注解@GlobalTransactional已正确添加
Seata Server日志显示全局事务已创建（global_table有记录）
业务SQL正常执行，但undo_log表没有任何记录
事务回滚时数据无法恢复

这种问题最迷惑人的地方在于：看起来分布式事务已经生效了（因为有global_table记录），但实际上RM根本没参与事务管理。就像你去餐厅吃饭，服务员给你上了菜单（开启事务），但厨师根本没收到点单（没有undo_log）。

通过DEBUG跟踪，我发现这种情况下SQL执行完全绕过了Seata的拦截器。也就是说，你的应用直接使用了原生数据源，而不是被Seata增强过的DataSourceProxy。

3. 自动代理失效的五大常见原因

经过多次踩坑和源码分析，我总结了自动代理失效的几个常见原因：

3.1 Spring Boot自动配置冲突

这是最常见的问题。当项目同时存在以下配置时容易出问题：

spring-boot-starter-jdbc
druid-spring-boot-starter
seata-spring-boot-starter

它们的自动配置可能存在加载顺序问题。我遇到过druid数据源先初始化，导致Seata来不及代理的情况。

3.2 多数据源场景配置不当

在多个数据源的场景下，如果没正确处理@Primary注解，Spring可能选择了错误的数据源。我曾经在一个项目里因为漏加@Primary注解，导致Seata代理了错误的数据源。

3.3 版本兼容性问题

Seata的不同版本对Spring Boot的支持度不同。比如：

Seata 1.4.x与Spring Boot 2.4.x的兼容性较好
Seata 1.5.x开始对Spring Boot 2.6.x有更好支持

用错版本组合可能导致自动代理失效。

3.4 配置属性覆盖不当

有些项目为了"优化"会手动设置：

seata: enable-auto-data-source-proxy: false

这直接关闭了自动代理功能，当然就不会生成undo_log了。

3.5 Bean加载顺序问题

当使用@Configuration手动配置数据源时，如果加载顺序不当，可能导致Seata的自动配置失效。这种情况在复杂的多模块项目中特别常见。

4. 手动配置DataSourceProxy的正确姿势

当自动代理失效时，手动配置是最可靠的解决方案。但这里有几个关键点需要注意：

4.1 基础配置方法

@Configuration public class DataSourceConfig { @Bean @ConfigurationProperties(prefix = "spring.datasource") public DruidDataSource druidDataSource() { return new DruidDataSource(); } @Primary @Bean public DataSource dataSource(DataSource druidDataSource) { return new DataSourceProxy(druidDataSource); } }

这里必须注意：

原生数据源不要加@Primary
DataSourceProxy必须加@Primary
建议使用@ConfigurationProperties统一管理配置

4.2 多数据源场景处理

对于多数据源，需要为每个数据源创建代理：

@Bean @Primary public DataSource routingDataSource( @Qualifier("masterDataSource") DataSource master, @Qualifier("slaveDataSource") DataSource slave) { Map<Object, Object> targetDataSources = new HashMap<>(); targetDataSources.put("master", new DataSourceProxy(master)); targetDataSources.put("slave", new DataSourceProxy(slave)); AbstractRoutingDataSource routing = new AbstractRoutingDataSource() { @Override protected Object determineCurrentLookupKey() { return DynamicDataSourceContextHolder.getDataSourceKey(); } }; routing.setTargetDataSources(targetDataSources); routing.setDefaultTargetDataSource(new DataSourceProxy(master)); return routing; }

4.3 必须关闭自动代理

在application.yml中一定要加上：

seata: enable-auto-data-source-proxy: false

否则会出现双重代理，导致奇怪的异常。

5. Spring Cloud Alibaba集成时的特殊问题

在使用Spring Cloud Alibaba时，有几个额外的坑需要注意：

5.1 Nacos配置冲突

当使用Nacos作为配置中心时，确保seata配置没有被意外覆盖。建议在bootstrap.yml中明确指定：

spring: cloud: nacos: config: shared-configs[0]: >@Bean public FilterRegistrationBean seataFilterRegistration() { FilterRegistrationBean registration = new FilterRegistrationBean(); registration.setFilter(new SeataFilter()); registration.addUrlPatterns("/*"); registration.setOrder(Ordered.HIGHEST_PRECEDENCE); return registration; }

5.3 Feign拦截器配置

使用Feign时，需要确保事务上下文正确传递：

@Configuration public class FeignConfig { @Bean public RequestInterceptor seataFeignInterceptor() { return template -> { String xid = RootContext.getXID(); if (StringUtils.isNotBlank(xid)) { template.header(RootContext.KEY_XID, xid); } }; } }

6. 问题排查的四步定位法

当遇到undo_log不生成的问题时，可以按照以下步骤排查：

检查代理是否生效：在DataSource.getConnection()处打断点，查看返回的是原生Connection还是ConnectionProxy
检查配置加载顺序：添加--debug启动参数，查看Seata自动配置是否生效
检查事务传播：在业务方法开始处打印RootContext.getXID()，确认事务上下文已绑定
检查SQL拦截：开启Seata的debug日志，观察是否输出"AT mode transaction begin"等日志