AT模式原理解析

AT模式原理解析🚨

官方文档参考 (opens new window)

TC相关的三张表

• global_table：全局事务表，每当有一个全局事务发起后，就会在该表中记录全局事务的ID
• branch_table：分支事务表，记录每一个分支事务的ID，分支事务操作的哪个数据库等信息
• lock_table：全局锁

两阶段提交协议的演变：

一阶段：

业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。

二阶段：

提交异步化，非常快速地完成。

回滚通过一阶段的回滚日志进行反向补偿。

一阶段加载

1. TM：seata-order.create()方法执行时，由于该方法具有@GlobalTranscational标志，该TM会向TC发起全局事务，生成XID（全局锁）
2. RM：StorageService.deduct()：写表，UNDO_LOG记录回滚日志（Branch ID），通知TC操作结果
3. RM：AccountService.deduct()：写表，UNDO_LOG记录回滚日志（Branch ID），通知TC操作结果
4. RM：OrderService.create()：写表，UNDO_LOG记录回滚日志（Branch ID），通知TC操作结果

在一阶段，Seata会拦截业务SQL,首先解析SQL语义，找到 业务SQL 要更新的业务数据，在业务数据被更新前，将其保存成 before image ,然后 执行 业务SQL 更新业务数据，在业务数据更新之后将其保存成 after image，最后生成行锁。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。

二阶段提交

正常：

二阶段如是顺利提交的话，因为 业务SQL 在一阶段已经提交至数据库，所以Seata框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。

异常：

二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的 业务SQL ，还原业务数据。

回滚方式便是用 before image 还原业务数据;但在还原前要首先要校验脏写，对比 数据库当前业务数据 和 after image

如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。

AT优势

AT 模式的一阶段、二阶段提交和回滚均交给了 Seata 框架来生成，用户只需专注编写 业务 SQL，轻松接入分布式事务，AT 模式是一种对业务无任何侵入的分布式事务解决方案。