本文属于b站
图灵课堂springcloud笔记系列。讲的好还不要钱，值得推荐。
上一篇快速体验了下seata AT模式解决分布式事务：
分布式事务seata(AT)与nacos整合-笔记2-CSDN博客
AT模式原理部分：
官网：Seata AT 模式 | Apache Seata
参照官网的文章再梳理下。
AT 模式如何做到对业务的无侵入 ？
在 AT 模式下，用户只需关注自己的“业务 SQL”，用户的 “业务 SQL” 作为一阶段，Seata 框架会自动生成事务的二阶段提交和回滚操作。
一阶段：
在一阶段，Seata 会拦截“业务 SQL”，首先解析 SQL 语义，找到“业务 SQL”要更新的业务数据，在业务数据被更新前，将其保存成“before image”，然后执行“业务 SQL”更新业务数据，在业务数据更新之后，再将其保存成“after image”，最后生成行锁。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。
- 二阶段提交：
二阶段如果是提交的话，分支事务收到TC请求会放到异步队列， 从异步队列 Seata 框架只需将一阶段保存的undolog(快照数据和行锁)删掉,提交本地事务即可。
- 二阶段回滚：
二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的“业务 SQL”，还原业务数据。回滚方式便是用“before image”还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务数据”和 “after image”，如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。
以上摘自：分布式事务 Seata 及其三种模式详解 | Apache Seata
执行过程中debug下，看看undo_log表数据。
这个就是rollback_info字段
{"@class": "io.seata.rm.datasource.undo.BranchUndoLog","xid": "192.168.59.96:8091:7566644201535901962","branchId": 7566644201535901964,"sqlUndoLogs": ["java.util.ArrayList", [{"@class": "io.seata.rm.datasource.undo.SQLUndoLog","sqlType": "UPDATE","tableName": "storage","beforeImage": {"@class": "io.seata.rm.datasource.sql.struct.TableRecords","tableName": "storage","rows": ["java.util.ArrayList", [{"@class": "io.seata.rm.datasource.sql.struct.Row","fields": ["java.util.ArrayList", [{"@class": "io.seata.rm.datasource.sql.struct.Field","name": "id","keyType": "PRIMARY_KEY","type": -5,"value": ["java.math.BigInteger", 1]}, {"@class": "io.seata.rm.datasource.sql.struct.Field","name": "count","keyType": "NULL","type": 4,"value": 133}, {"@class": "io.seata.rm.datasource.sql.struct.Field","name": "update_time","keyType": "NULL","type": 93,"value": ["java.time.LocalDateTime", 1734145920000]}]]}]]},"afterImage": {"@class": "io.seata.rm.datasource.sql.struct.TableRecords","tableName": "storage","rows": ["java.util.ArrayList", [{"@class": "io.seata.rm.datasource.sql.struct.Row","fields": ["java.util.ArrayList", [{"@class": "io.seata.rm.datasource.sql.struct.Field","name": "id","keyType": "PRIMARY_KEY","type": -5,"value": ["java.math.BigInteger", 1]}, {"@class": "io.seata.rm.datasource.sql.struct.Field","name": "count","keyType": "NULL","type": 4,"value": 132}, {"@class": "io.seata.rm.datasource.sql.struct.Field","name": "update_time","keyType": "NULL","type": 93,"value": ["java.time.LocalDateTime", 1734165472000]}]]}]]}}]]
}关于读写隔离理解
官网文章有图方便理解，业务一开启全局事务，其中包含分支事务A（修改 A）和分支事务 B（修改 B），业务二在执行全局事务过程中，分支事务 A 提交前注册分支事务获取全局锁时，发现业务业务一全局锁还没执行完，因此业务二提交不了，抛异常回滚，所以不会发生脏写。
传统意义的脏读是读到了未提交的数据，Seata 脏读是读到了全局事务下未提交的数据，全局事务可能包含多个本地事务，某个本地事务提交了不代表全局事务提交了。绝大部分场景下默认级别读未提交没有问题的，针对特殊场景加select for update语句会在执行 SQL 前检查全局锁是否存在，只有当全局锁完成之后，才能继续执行 SQL，这样就防止了脏读。
