Seata 的事务回滚是怎么实现的？

回答重点

Seata 一共有四种事务模式，不同模式下回滚策略是不一样的。

在 AT 模式中，Seata 的回滚机制依赖于数据库中的 undo_log 表。每当执行数据库操作（如 INSERT、UPDATE、DELETE）时，Seata 的 RM 会在数据库中记录操作前的数据快照，并存储在 undo_log 中。这个过程在业务操作的本地事务提交前完成。

如果全局事务中任一分支事务失败，或者 TM 向 TC 发起了全局回滚请求，TC 会通知所有相关的 RM 执行回滚操作。

在接收到回滚请求后，RM 从 undo_log 中读取数据的原始状态，并将数据恢复到操作前的状态。这意味着，即使数据库中已经进行了 UPDATE 或 DELETE 操作，RM 也能根据 undo_log 中的快照还原原始数据。

在 TCC 模式下，事务回滚是通过业务实现的 Cancel 方法来完成的。开发者需要在业务代码中定义 Try（预留资源）、Confirm（确认操作）、Cancel（取消操作）三个阶段。

当全局事务需要回滚时，Seata 会调用对应的 Cancel 方法来撤销 Try 阶段中预留的资源。Cancel 操作的逻辑由业务代码实现，通常是对 Try 操作的逆操作。

SAGA 模式通过定义每个业务操作的补偿操作来实现回滚。每个子事务都有一个对应的补偿操作，用于在子事务失败时撤销之前的操作。

如果某个子事务执行失败，SAGA 模式会按相反的顺序调用之前已完成的子事务的补偿方法，从而将整个业务流程回滚到初始状态。

XA 模式基于标准的 XA 协议实现回滚。在第一阶段中，事务协调器（TC）向各个资源管理器（RM）发送预备指令。所有参与的资源在执行操作后暂时不提交，而是等待 TC 的最终决策。

如果 TC 选择回滚事务，它会通知各个 RM 执行 ROLLBACK 操作。RM 根据数据库内置的 XA 支持来回滚数据，确保所有资源恢复到未提交之前的状态。