获课：97it.top/17267/

### 分布式事务解决方案：Seata AT模式与TCC模式在微服务中的落地实践

在微服务架构的演进过程中，数据一致性是核心挑战之一。随着业务服务的拆分，原本在单体应用中通过本地数据库事务即可保证的ACID特性，在分布式环境下变得复杂。Seata作为一款开源的分布式事务解决方案，提供了AT（Automatic Transaction）和TCC（Try-Confirm-Cancel）两种主流模式，它们在落地实践中各有侧重，适用于不同的业务场景。

#### 一、AT模式：无侵入的自动补偿机制

AT模式的核心价值在于其对业务代码的无侵入性，它通过两阶段提交协议来保证分布式事务的一致性，极大地降低了开发者的使用门槛。

在架构层面，Seata定义了三个核心角色：事务管理器（TM）负责定义全局事务的边界；资源管理器（RM）负责管理分支事务的资源；事务协调器（TC）则作为独立服务维护全局事务的状态。这种设计实现了事务控制与业务逻辑的解耦。

AT模式的执行流程分为两个阶段。在第一阶段（准备阶段），RM会拦截业务SQL，在执行前记录数据的“前镜像”（Before Image），执行后记录“后镜像”（After Image），并生成行锁。这些操作与业务本地事务在同一个数据库事务中提交，保证了原子性。在第二阶段，如果全局事务提交，TC会通知各RM异步删除日志；如果全局事务回滚，RM则利用“前镜像”生成反向SQL，还原数据。这种机制使得开发者几乎无需修改业务代码，仅需添加注解即可接入。

#### 二、TCC模式：高性能的业务侵入式方案

相较于AT的自动补偿，TCC模式将控制权交给了业务层，通过三个明确的业务接口实现资源的锁定与释放。这种模式虽然对业务有侵入性，但换来了更高的灵活性和并发性能。

TCC模式同样遵循两阶段提交的思想，但其语义更贴近业务逻辑。

- **Try阶段**：执行业务检查并预留资源。例如，在扣减库存时，不是直接操作主库存，而是将数量转移到“冻结”字段中。这一阶段不修改核心业务数据，且尽早释放数据库锁，从而提高了并发度。

- **Confirm阶段**：在所有分支的Try阶段成功后执行。此阶段不再做任何检查，直接确认并消耗Try阶段预留的资源。该操作必须是幂等的。

- **Cancel阶段**：如果任一分支失败，则触发Cancel操作，将Try阶段预留的资源进行回滚，例如将冻结的资金解冻。

TCC模式通过业务层面的资源隔离，避免了数据库层面的长事务锁竞争，因此在高并发、高性能要求的场景下表现优异。

#### 三、落地实践中的权衡与选型

在实际项目落地时，技术选型本质上是业务需求与成本的博弈。

从开发成本来看，AT模式具有绝对优势，几乎零代码侵入，适合基于关系型数据库的简单CRUD操作。而TCC模式需要为每个接口编写Try、Confirm、Cancel三个方法，并处理幂等性、防悬挂、空回滚等复杂问题，开发量大，对业务逻辑有较强的侵入性。

从性能与一致性角度来看，AT模式依赖于全局锁和Undo Log，在第一阶段需要持有全局锁，虽然本地事务提交快，但在高并发场景下可能存在锁竞争。TCC模式在Try阶段只做预留，不修改核心数据，锁粒度小，并发度高，且一致性由业务逻辑严格控制，适用于对数据一致性要求极高的核心业务，如支付、金融领域。

综上所述，对于一致性要求极高且能接受一定性能损耗的场景，AT模式是快速落地的首选；而对于追求极致性能、需要操作非数据库资源或逻辑极其复杂的业务，TCC模式则是更优的选择。