TC相关的表解析

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

AT 模式如何做到对业务的无侵入

一阶段步骤：

• TM：bussiness-service.buy(long，long)方法执行时，由于该方法具有 @GlobalTransactional 标志，该TM会向TC发起全局事务，生成XID（全局锁）。

• RM：OrderService.create(long,long)：写表，undo_log记录回滚日志（Branch ID），通知TC操作结果。

• RM：StorageService.changeNum(long,long)：写表，undo_log记录回滚日志（Branch ID），通知TC操作结果。
  RM写表的过程，Seata会拦截业务SQL，首先解析SQL语义，在业务数据被更新前，将其保存成before image，然后执行业务SQL，在业务数据更新之后，再将其保存成after image，最后生成行锁。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。

二阶段步骤：

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

• 正常：TM执行成功，通知TC全局提交，TC此时通知所有的RM提交成功，删除UNDO_LOG回滚日志

• 异常：TM执行失败，通知TC全局回滚，TC此时通知所有的RM进行回滚，根据UNDO_LOG反向操作，使用beforeimage 还原业务数据，删除UNDO_LOG，但在还原前要首先要校验脏写，对比“数据库当前业务数据”和 afterimage，如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。

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

写隔离

一阶段本地事务提交前，需要确保先拿到 全局锁 。
拿不到全局锁 ，不能提交本地事务。
拿全局锁的尝试被限制在一定范围内，超出范围将放弃，并回滚本地事务，释放本地锁。
两个全局事务 tx1 和 tx2，分别对 a 表的 m 字段进行更新操作，m 的初始值 1000。
tx1 先开始，开启本地事务，拿到本地锁，更新操作 m = 1000 - 100 = 900。本地事务提交前，先拿到该记录的全局锁，本地提交释放本地锁。 tx2 后开始，开启本地事务，拿到本地锁，更新操作 m = 900 - 100 = 800。本地事务提交前，尝试拿该记录的全局锁，tx1 全局提交前，该记录的全局锁被 tx1 持有，tx2 需要重试等待全局锁。

tx1 二阶段全局提交，释放全局锁。tx2 拿到全局锁提交本地事务。

如果 tx1 的二阶段全局回滚，则 tx1 需要重新获取该数据的本地锁，进行反向补偿的更新操作，实现分支的回滚。
此时，如果 tx2 仍在等待该数据的全局锁，同时持有本地锁，则 tx1 的分支回滚会失败。分支的回滚会一直重试，直到 tx2 的全局锁等锁超时，放弃全局锁并回滚本地事务释放本地锁，tx1 的分支回滚最终成功。
因为整个过程全局锁在 tx1 结束前一直是被 tx1 持有的，所以不会发生脏写的问题。

读隔离

在数据库本地事务隔离级别读已提交（Read Committed）或以上的基础上，Seata（AT 模式）的默认全局隔离级别是读未提交（Read Uncommitted）。
如果应用在特定场景下，必需要求全局的读已提交，目前 Seata 的方式是通过 SELECT FOR UPDATE 语句的代理。

SELECT FOR UPDATE 语句的执行会申请全局锁，如果全局锁被其他事务持有，则释放本地锁（回滚 SELECT FOR UPDATE 语句的本地执行）并重试。这个过程中，查询是被 block 住的，直到全局锁拿到，即读取的相关数据是 已提交 的，才返回。
出于总体性能上的考虑，Seata 目前的方案并没有对所有 SELECT 语句都进行代理，仅针对 FOR UPDATE 的 SELECT 语句。

AT模式特点

• 优点：对代码无侵入；并发度高，本地锁在一阶段就会释放；不需要数据库对XA协议的支持。
• 缺点：只能用在支持ACID的关系型数据库；SQL解析还不能支持全部语法。