Apache Seata 在SpringMVC中数据源重复代理导致主键冲突问题解析

问题背景

在使用Apache Seata分布式事务框架与SpringMVC（非Spring Boot）集成时，开发人员遇到了一个典型的数据源代理问题。具体表现为在事务处理过程中，Seata服务器端日志出现主键冲突错误，提示"Duplicate entry for key 'PRIMARY'"。

问题现象分析

从错误日志中可以清晰地看到，Seata服务器在执行全局锁批量获取操作时，遇到了主键重复的问题。错误发生在LockStoreDataBaseDAO类的doAcquireLocks方法中，这表明Seata在尝试向锁表插入记录时，发现相同的主键已经存在。

根本原因

经过深入分析，问题的根源在于数据源被多次代理：

1. 自动代理与手动代理冲突：配置类中同时使用了@EnableAutoDataSourceProxy注解和手动创建DataSourceProxy的方式，导致数据源被代理了两次。

2. SpringMVC环境特殊性：与Spring Boot不同，SpringMVC环境下需要更显式地配置数据源代理，自动配置机制可能不如Spring Boot完善。

3. 锁表操作机制：Seata在获取全局锁时，会先尝试批量插入锁记录，如果记录已存在则会抛出异常，然后进入重试逻辑（先查询后插入）。

解决方案

针对这一问题，我们推荐以下解决方案：

1. 统一代理方式：移除@EnableAutoDataSourceProxy注解，仅保留手动创建DataSourceProxy的方式，避免重复代理。

2. 显式配置数据源：在SpringMVC的配置文件中明确配置Seata数据源代理，确保代理只发生一次。

3. 检查锁表状态：建议检查Seata服务器的lock_table表，确认是否存在异常的锁记录。

最佳实践建议

1. 环境适配：在非Spring Boot环境下使用Seata时，建议采用更显式的配置方式，避免依赖自动配置。

2. 日志监控：加强对Seata服务器日志的监控，特别是锁相关的错误日志，可以早期发现问题。

3. 版本兼容性：确保使用的Seata版本与SpringMVC版本兼容，不同版本间的代理机制可能有差异。

4. 配置检查：在应用启动时，可以添加日志输出数据源的类型信息，确认代理是否按预期工作。

技术深度解析

Seata的全局锁机制是其AT模式的核心组件之一。当业务操作涉及多行数据时，Seata会尝试批量获取这些行的锁。在锁获取过程中：

1. 首先尝试批量插入锁记录
2. 如果遇到主键冲突（记录已存在），会记录错误日志
3. 然后进入重试逻辑，改为先查询后插入的方式
4. 最终确保锁的正确获取或等待超时

这一机制保证了分布式环境下数据的一致性，但也对数据源代理的正确性提出了严格要求。重复代理可能导致锁记录插入行为异常，从而触发主键冲突。

总结

在分布式系统开发中，Seata作为一款优秀的分布式事务解决方案，其正确使用需要开发人员深入理解其工作原理。特别是在与传统SpringMVC集成时，更需要注意配置的精确性。通过本文的分析和解决方案，希望能帮助开发者避免类似问题，构建更健壮的分布式应用系统。