从单机代理到分布式博弈：彻底吃透 Spring 事务与 Seata 架构演进

Sat, 14 Mar 2026 12:00:00 +0900

在 Java 后端开发中，处理数据库事务往往是业务逻辑的重中之重。在单体应用时代，Spring 提供的 @Transactional 注解仿佛拥有黑魔法，只需轻轻一点，繁琐的提交与回滚便迎刃而解。然而，当系统迈入微服务与多数据源时代，这层魔法瞬间失效，开发者被迫直面分布式系统中最残酷的 CAP 定理。

本文将从 @Transactional 的底层代理机制切入，剖析其致命的使用陷阱，并顺着架构演进的脉络，深度解构跨库场景下的分布式事务解决方案及其背后的妥协哲学。

一、 @Transactional 的底层真相：代理模式的完美演出

在纯 JDBC 时代，一段包含事务的业务代码充斥着获取连接、关闭自动提交、手动 Commit 以及 Catch 异常后 Rollback 的模板代码。@Transactional 的核心价值，就是用声明式的方式将这些非业务关注点彻底剥离。

这种剥离的底层支撑，正是基于 CGLIB 或 JDK 动态代理的 AOP 技术。当 Spring 扫描到类或方法上的 @Transactional 注解时，它并不会将真实的业务对象暴露给 IoC 容器，而是生成一个包含 TransactionInterceptor（事务拦截器）的代理子类。

真正的执行流如下：

拦截接管：外部请求打在代理对象上，拦截器向数据库连接池申请 Connection，并执行 setAutoCommit(false)。
线程绑定：Spring 将该连接放入基于 ThreadLocal 的同步管理器中。这保证了业务方法内部触发的所有 MyBatis 或 Hibernate 操作，都能从当前线程拿到同一个物理连接，从而处于同一个事务上下文中。
执行与收尾：拦截器调用真实业务方法。若正常返回则取出连接执行 commit()；若捕获到未处理的 RuntimeException，则执行 rollback()。最后归还连接，清理现场。

没有任何黑魔法，@Transactional 仅仅是一段被代理类包裹起来的、硬编码的 JDBC try-catch 逻辑。

二、致命陷阱：为何 this 调用会让事务裸奔？

理解了代理机制，就能看穿 Spring 事务中最令人抓狂的陷阱：类内部方法自调用（Self-Invocation）导致事务失效。

假设 OrderService 中有一个未加事务的 createOrder() 方法，它在内部调用了同类中被 @Transactional 修饰的 pay() 方法。此时，事务将绝对不会生效。

在 Spring 容器中，此时存在两个对象：一个是真实的业务对象（老板），另一个是包裹在外的代理对象（保安）。外部调用 createOrder() 时，由于没有事务注解，代理对象（保安）直接放行，请求进入了真实对象（老板）。在真实对象内部执行 this.pay() 时，this 指针永远指向当前内存中的真实对象本身。这意味着它根本不会绕回大门口让代理对象重新拦截。这是一次极其纯粹的“裸奔”调用，自然没有人为其开启和提交事务。

破解这一困局的架构思路有三：

正统解法：将 @Transactional 移至外层的统一入口方法上，让整个业务链路处于外层大事务的庇护之下。
架构解耦：将扣款逻辑剥离至独立的 PaymentService，将内部自调用转化为跨类的外部调用，从而重新触发代理拦截。
自我注入：在类内部通过 @Autowired 注入自身的代理对象，替代 this 进行调用。

三、跨越单库边界：分布式事务的深水区

当业务复杂度提升，一个请求需要同时操作订单库（DB1）和库存库（DB2）时，基于单机 ThreadLocal 绑定的 @Transactional 彻底宣告破产。若操作 DB1 成功而操作 DB2 崩溃，DB1 的数据已永久落盘，无法撤销。

为了解决跨库数据一致性，业界演进出了不同的分布式事务架构：

1. 强一致性的噩梦：XA / 2PC 协议

这是关系型数据库原生的两阶段提交方案。事务协调者（TM）在第一阶段要求所有数据库执行 SQL 但不提交。若全员就绪，第二阶段才统一下达 Commit 指令。其致命缺陷在于：整个两阶段期间，相关数据行被死死锁住。在互联网高并发场景下，这种长事务锁会导致系统吞吐量断崖式下跌，目前几乎已被全面弃用。

2. 现代微服务标配：Seata AT 模式

阿里开源的 Seata 通过代理数据源（DataSource Proxy）给出了一种极其精妙的妥协方案。

在 AT 模式下，当向 DB1 执行 update 语句时，Seata 会在执行前后查询数据镜像，生成补偿日志（undo_log）。最关键的一步是：Seata 会毫不犹豫地立刻提交 DB1 的本地事务并释放行锁。

若全局事务顺利，协调器只需异步通知各节点清理 undo_log；若发生异常，协调器则指令 DB1 节点读取 undo_log 中的前置镜像，反向生成补偿 SQL 恢复数据。

3. 高并发的终极答案：MQ 与最终一致性

在双 11 扣减库存等极端并发场景下，即使是 Seata 也会显得过重。系统通常会放弃 ACID，转向 BASE 理论。通过本地消息表与 RocketMQ/Kafka 等消息队列，将同步的分布式事务降级为异步的事件通知。只要依靠 MQ 的重试机制以及下游服务的幂等性设计，就能保证数据在经历短暂的延迟后，达到最终一致性。

四、架构的妥协：容忍脏读，严防脏写

敏锐的开发者会发现 Seata AT 模式的代价：当 DB1 的本地事务在第一阶段提交后，不仅是应用，任何直接连接到 DB1 的客户端，都能立刻查询到这条刚刚写入的新数据。若随后全局事务回滚，这段时间差内暴露的数据，就是不折不扣的全局脏读（Read Uncommitted）。

这是框架为了释放底层行锁、换取高吞吐量所必须付出的隔离性降级代价。在大多数业务场景下，短暂的脏读是可以容忍的（如视为网络延迟）。但框架绝对不能容忍的是全局脏写。

如果全局事务 A 在等待全局决议时，全局事务 B 试图修改 DB1 的同一行数据，一旦 A 决定回滚并应用 undo_log，就会将 B 合法写入的数据抹除。为了防止脏写，Seata 引入了全局锁（Global Lock）。在第一阶段本地提交前，事务必须成功向协调器申请并持有该数据行的全局锁。这强行保证了在读未提交的隔离级别下，依然维持着严格的 Write Committed（写已提交）底线。

五、结语

从 @Transactional 的单机 AOP 魔法，到 Seata AT 模式“本地提交+反向补偿”的架构智慧，再到 MQ 异步解耦的最终一致性。我们清晰地看到：分布式系统没有银弹，所有的技术方案都是在 CAP 定理的边界内进行取舍。用隔离性换取可用性，用复杂的补偿逻辑换取底层的性能释放，正是现代后端架构演进的核心旋律。

分布式事务 on Tech In Sight

从单机代理到分布式博弈：彻底吃透 Spring 事务与 Seata 架构演进

一、 @Transactional 的底层真相：代理模式的完美演出

二、 致命陷阱：为何 this 调用会让事务裸奔？

三、 跨越单库边界：分布式事务的深水区