Seata 工作原理与源码主线

Seata AT 模式通过数据源代理、全局事务协调和回滚日志降低业务改造量，但它没有消除分布式事务成本。使用前先确认 SQL、数据源和隔离要求受支持，再用故障演练验证回滚。

Table of contents

三个角色和一个标识

• TC（Transaction Coordinator）：保存全局事务与分支状态，驱动提交或回滚。
• TM（Transaction Manager）：划定全局事务边界，向 TC 开始、提交或回滚。
• RM（Resource Manager）：管理数据库等分支资源，注册分支并执行二阶段动作。
• XID：全局事务标识，必须沿服务调用传播。

@GlobalTransactional 通常标记 TM 边界。每个参与数据源由 RM 代理；漏代理一个数据源，就会出现“全局回滚了，但这张表没回滚”。

AT 两阶段

一阶段中，代理解析更新 SQL，读取前镜像和后镜像，把业务修改与 undo_log 写入放在同一本地事务，并向 TC 申请全局锁。二阶段提交通常异步删除回滚日志；二阶段回滚则用前镜像恢复，并用后镜像检查数据是否被外部修改。

@GlobalTransactional
public void placeOrder() {
    inventoryService.deduct();
    accountService.debit();
}

这段代码只有在数据源代理、XID 传播、undo_log、注册中心和 TC 都正确时才成立。参考 Seata AT 模式官方说明搭建验证环境。

源码从请求链读

按“全局事务拦截器 → TM 开启事务 → XID 传播 → 数据源代理 → SQL 执行器 → 分支注册 → undo_log → TC 二阶段调度”追踪。每走一步，记录输入、持久状态、网络消息和失败后的重试者。

重点演练脏写冲突、TC 重启、分支超时、二阶段重复通知、回滚时后镜像不匹配和 undo_log 清理积压。AT 更适合关系数据库的短事务；长时间人工审批用 Saga 或持久工作流更自然。

下一步

继续阅读08-12 RabbitMQ 入门：交换机、队列与路由，建立消息从发布者到消费者的完整路径。