5.5.6 使用 Seata 框架处理分布式事务

Seata（Simple Extensible Autonomous Transaction Architecture，简单可扩展自治事务框架），是蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。 Seata 提供了一种简单、可扩展和自主的事务解决方案，可以支持微服务架构中的分布式事务处理。

Seata 在阿里巴巴经历了多年”双 11“洗礼，通过多年的沉淀和积累， Seata 如今已成为分布式事务首选框架，它提供了多种事务模型支持，如 TCC、SAGA 和 XA 以及本文要介绍的 AT 模式。

1. Seata 角色

在 Seata 的架构设计中存在三种角色，即事务管理者、资源管理者以及事务协调者。

事务管理者（TM）：负责驱动事务协调者（TC）执行全局事务的开启、提交和回滚操作，其通常由发起全局事务的业务充当。
资源管理者（RM）：按照事务协调者（TC）的指令，执行分支事务的分支的提交、回滚操作，并向事务协调者汇报当前分支事务的状态，其一般由全局事务中涉及的所有分支业务充当。
事务协调者（TC）：维护全局事务的状态，执行全局事务的提交和回滚操作，启动资源管理者（RM）执行分支事务的提交和回滚操作，由 Seata-Server 充当事务的协调者。

AT 模式是基于二阶段提交协议演变而来，它与二阶段提交协议一样分为两个阶段来实现多个分支事务之间的原子提交。与二阶段提交协议不同的事， AT 模式缩小了分支事务资源锁定的范围。

AT 模式在第一阶段任务执行完成后，会释放分支事务资源，不需要像二阶段提交协议一样，要等到整个协议完成协商之后才能释放资源，具体的执行逻辑如下。

第一阶段，TM 向 TC 注册全局事务，TC 会为本地全局事务生成唯一的 XID 并返回给 TM，后续 TM 与 RM 交互的请求都会携带 XID。
当 RM 收到 TM 执行的指令后，需要先获得本地锁才能执行分支事务并记录 Undo 和 Redo 日志。RM 根据 Undo 日志锁涉及的数据向 TC 申请该数据的全局锁，在获得全局锁之后， RM 会提交本地事务并释放本地锁。
最后 RM 向 TC 和 TM 上报分支事务的执行状态，完成第一阶段工作。

总体流程如下图所示：

第二阶段，在 TM 调用 RM 的过程中，如果存在一个或多个 RM 处理发生异常的情况，则 TM 向 TC 发送 Rollback 指令， TC 将向所有的 RM 发送 Rollback 指令，在等待所有的 RM 反馈之后，删除全局事务，释放全局锁。

在 RM 收到 Rollback 指令后， RM 依然拥有事务数据的全局锁，但没有获得本地锁，因此 RM 需要重新获取本地锁，然后根据第一阶段记录的 Undo 日志对数据进行回溯，即将数据恢复至全局事务开启之前的状态，提交重做事务后，释放本地锁。

最后 RM 向 TC 上报分支事务状态， TC 释放全局锁，完成本次全局事务的回滚。流程图如下：

AT 模式与两阶段提交最大的区别在于，AT 模式缩小了分支事务资源的锁定范围。虽然 AT 模式提高了系统的工作效率，但其复杂度也相应提高了，由于 AT 模式在第一阶段就提交了分支事务，因为第二阶段也需要进行相应的变化，具体总结如下：

Seata 的官方示例中包含了多种分布式事务模型的演示代码，AT 模式的 Demo 例子给出了一个典型的分布式事务场景。

Demo 中的采购交易系统一个典型的微服务架构，其中有库存、账户、订单三个子服务，子服务之间相互独立，并遵循存储隔离(Data Storage Segregation, DSS) 原则。

在这个系统中，一个采购交易的流程：

很明显，以上 3 个步骤必须要么全部成功，要么全部失败，否则系统的数据就会发生错乱。使用 AT 模式解决这个问题的思路其实很简单，一句话概括就是：在分布式事务过程中，记录待修改的数据修改前和修改后的值到 undo_log 表，如果交易中出现异常，就通过表中的数据做回滚，返回事务发生之前的状态。

由于演示代码细节较多，感兴趣的读者可以从 Github 库中下载学习。

https://github.com/seata/seata-samples/tree/master/dubbo