Seata是一款分布式事务处理应用的框架，不少开发者心中都有一个疑问：Seata的AT模式会不会出现脏读呢？答案是肯定的，不过它出现的脏读情况和传统意义上的脏读有所不同。传统脏读指的是在MySQL本地事务场景下，一个事务读取到了其他未提交事务的数据。而Seata的AT模式中，存在这样一种情况：一个事务可能读取到其他分支事务（也是本地事务）已提交，但后续可能因全局事务回滚而撤销的数据。这听起来有些绕，下面详细讲解，看完后大家就能理解了。

要想深入理解这个问题，首先得清楚Seata的AT模式的工作原理。AT模式的核心机制是两阶段提交：

• 第一阶段：本地事务会立即提交，同时释放本地锁，这使得数据对其他事务可见。
• 第二阶段：全局事务会依据协调结果来决定最终是提交还是回滚，这个过程借助undo log来进行补偿操作。

了解了工作原理后，我们来设想一个场景。假设有三个模块，分别是交易模块、订单模块和库存模块。在一次下单过程中，为确保数据的一致性，代码可能会像下面这样编写：

import io.seata.spring.annotation.GlobalTransactional; import org.springframework.beans.factory.annotation.Autowired; @Service public class TradeService { @Autowired private InventoryService inventoryService; @Autowired private OrderService orderService; @GlobalTransactional public boolean buy() { //库存扣减 inventoryService.decreaseInvenroty(); //创建订单 orderService.createOrder(); } } 

在这段代码里，@GlobalTransactional开启了一个分布式事务。在这个事务中，会先调用库存服务进行库存扣减，然后再调用订单服务创建订单。整个大致的流程是这样的：

1. 在交易模块（Trade）中，首先创建全局事务。
2. 库存模块（Inventory）介入：
   • 2.1注册分支事务。
   • 2.2进行库存扣减操作，并记录undo log 。这里要注意，库存模块在数据库上的操作是基于数据库的本地事务进行的。之所以借助本地事务，是为了保障undo log（Seata使用的undo log和MySQL中MVCC的undo log不是同一个概念）和库存扣减操作的原子性。而且，这一步执行完成后，数据库的本地事务会提交。
3. 订单模块（Order）参与：
   • 3.1注册分支事务。
   • 3.2创建订单，并记录undo log 。

这里关键的一点是，当库存模块完成扣减操作，数据库的本地事务提交后，不管处于何种事务隔离级别，其他事务都能查询到提交后的新值。想象一下，如果库存扣减成功，但在创建订单时失败了，此时整个分布式事务需要回滚，会依据库存库中的undo log进行回滚操作。那么在库存模块提交后、全局事务回滚前，如果有其他事务来查询库存数据，就会读到一个本该回滚的值。这就是Seata的AT模式下出现的脏读情况，它发生在全局事务的过程中，其他事务读到了全局事务尚未最终确定提交（后续可能会回滚）的数据。

既然AT模式存在这样的脏读问题，那有没有办法避免呢？确实有一个办法，就是在查询时使用@GlobalTransactional + select * ... for update 。不过这个方法比较笨拙，它虽然能解决脏读问题，但在实际应用中会带来一些弊端。因为事务已经提交，要避免其他事务读取数据比较困难，即便实现了，也会极大地降低系统的可用性。所以，如果项目中对脏读的容忍度为零，不接受这种情况，那就不建议使用AT模式，可以考虑选择其他事务方案，例如TCC模式。