Seata使用AT模式
一、简介
Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案
二、应用集成Seata使用AT模式的前提：
-
基于支持本地 ACID 事务的关系型数据库
-
Java 应用，通过 JDBC 访问数据库
三、AT模式的整体机制是由两阶段提交协议的演变：
-
一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源
-
二阶段：
-
提交异步化，非常快速地完成
-
回滚通过一阶段的回滚日志进行反向补偿
-
四、Seata的术语
-
TC（Transaction Coordinator）事务协调器：就是Seata，负责维护全局事务和分支事务的状态，负责通知
RM 执行回滚或 提交 -
TM（Transaction Manager）事务管理器：标注全局@GlobalTransactional启动入口动作的微服务模块（比如订单模块），它是事务的发起者，
TM的职责是开启一个全局事务，并接收RM分支事务执行状态汇报，然后向TC报告全局事务是全局提交呢 ？还是全局回滚 ？ -
RM（Resource Manager）资源管理器：在微服务框架中对应具体的某个微服务为事务的分支，
RM的职责是：执行每个分支事务，并向TM汇报分支事务执行结果
执行过程
-
TM向 TC申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的 XID
-
XID在微服务调用链路的上下文中传播; RM 向 TC注册分支事务，将其纳入 XID 对应全局事务的管辖
-
TM 向 TC 发起针对 XID 的全局提交或回滚决议
-
TC 调度 XID下管辖的全部分支事务完成提交或回滚请求
五、Seata AT模式一阶段整体操作流程如下图所示：
一阶段：准备阶段
-
业务 SQL 解析与执行：
-
RM 拦截业务 SQL，解析 SQL 类型（如 update、insert）、表名、条件等信息
-
执行 SQL 前，查询并保存数据的 前镜像（before image），即修改前的数据状态
-
-
生成回滚日志：
-
执行 SQL 后，查询并保存数据的 后镜像（after image），即修改后的数据状态
-
将前镜像（before image）、后镜像（after image）以及 SQL信息 组成回滚日志（undo log），插入到 undo_log 表中
-
-
注册分支事务：
- RM 会注册一个分支事务到事务协调者TC中，保持在Seata的 branch_table表中，并申请全局锁（Seata的lock_table表中），确保事务隔离性
-
提交本地事务：
- 业务数据和回滚日志在同一个本地事务中提交，释放本地锁和连接资源，并向TC报告事务状态
六、Seata AT模式二阶段整体操作流程如下图所示：
二阶段提交
-
提交：
-
如果所有分支事务成功，TC 通知 RM 提交全局事务
-
RM 异步删除 undo_log 记录 和 Seata的行锁，完成事务提交
-
二阶段回滚
-
回滚：
-
如果任一分支事务失败，TC 通知 RM 回滚全局事务
-
RM 回滚方式根据 undo_log 记录中的 "before image" 还原业务数据；但在还原前要首先要校验脏写，对比"数据库当前业务数据 和 "after image" 如果两份数据完全一致就说明没有脏写，可以还原业务数据
-
删除 undo_log 记录 和 Seata的 lock_table表 中锁记录，完成事务回滚
-
七、AT案例演示：
AT模式只需要将配置中的data-source-proxy-mode: XA改为AT，或者是直接去除这一行配置即可
AT模式会使用到我们前面执行过脚本的几个数据库表:
-
回滚日志表：undo_log
-
分支事务表：branch_table
-
全局事务表：global_table
-
全局锁表：lock_table
全局事务表跟分支事务表是一对多的关系，一个全局事务对应多个分支事务
测试正常流程
我们这里把余额表的数据修改回原来的money=1000、库存表的数据修改回 count = 10
发起请求：http://localhost:8082/order?userId=user112233&commodityCode=storage112233&count=1&money=200
当断点停这里的时候，我们看db_account和db_order两个数据库的undo_log表，在这两个表中各自生成了一条日志记录，
xid都为：192.168.3.1:8091:5215564685333463148，这说明他们确实是在同一个全局事务当中
再看订单表和余额表，可以看到数据库中都是提交了的
我们再把断点放开，可以看到日志表的两条记录都被删除了，这也印证了我们上面的原理图
测试回滚流程
我们再次把余额表的数据修改回原来的money=1000、库存表的数据修改回 count = 10。
用样打个断点
发起请求：http://localhost:8082/order?userId=user112233&commodityCode=storage112233&count=11&money=200
这回请求的库存 count 为11，而库存为10，明显是不够的，所以肯定会报错
当上图断点到扣减库存这里的时候，我们看订单和余额对应的快照日志表，新增了各一条日志，可以看到他们的全局事务 xid 是相同的
我们看一下余额的快照信息 rollback_info:
这里主要记录了前置镜像beforeImage和后置镜像afterImage，也就是我们说的快照，可以看到他的valuew值，前置的（扣减前的余额）为1000，后置的（扣减后的余额）为800，它恢复的时候就是先查询后置的value是否跟现在的value相等，如果相等，则恢复成前置镜像的value值。如果不相等，默认他会在一定的时间内重试5次
{
"@class": "io.seata.rm.datasource.undo.BranchUndoLog",
"xid": "192.168.3.1:8091:5215564685333463152",
"branchId": 5215564685333463154,
"sqlUndoLogs": [
"java.util.ArrayList",
[
{
"@class": "io.seata.rm.datasource.undo.SQLUndoLog",
"sqlType": "UPDATE",
"tableName": "account_tbl",
"beforeImage": {
"@class": "io.seata.rm.datasource.sql.struct.TableRecords",
"tableName": "account_tbl",
"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": 4,
"value": 1
},
{
"@class": "io.seata.rm.datasource.sql.struct.Field",
"name": "money",
"keyType": "NULL",
"type": 4,
"value": 1000
}
]
]
}
]
]
},
"afterImage": {
"@class": "io.seata.rm.datasource.sql.struct.TableRecords",
"tableName": "account_tbl",
"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": 4,
"value": 1
},
{
"@class": "io.seata.rm.datasource.sql.struct.Field",
"name": "money",
"keyType": "NULL",
"type": 4,
"value": 800
}
]
]
}
]
]
}
}
]
]
}
再看订单表和余额表，订单已经创建完成、余额也已经扣减成功。
我们放开断点，可以看到库存的的服务报错了，那么前面的 db_order 的订单表和 db_account 的余额表就会回滚，而回滚就是根据 undo_log 表的回滚日志
再看回滚后的数据
八、官网示例说明工作原理机制
以一个示例来说明整个 AT 分支的工作过程
业务表：product
AT 分支事务的业务逻辑：
update product set name = 'GTS' where name = 'TXC';
一阶段
过程：
-
解析 SQL：得到 SQL 的类型（UPDATE），表（product），条件（where name = ‘TXC’）等相关的信息
-
查询前镜像：根据解析得到的条件信息，生成查询语句，定位数据
select id, name, since from product where name = 'TXC';
得到前镜像：
1、执行业务 SQL：更新这条记录的 name 为 ‘GTS’
2、查询后镜像：根据前镜像的结果，通过 主键 定位数据
select id, name, since from product where id = 1;
得到后镜像：
1、插入回滚日志：把前后镜像数据以及业务 SQL 相关的信息组成一条回滚日志记录，插入到 UNDO_LOG 表中
{
"branchId": 641789253,
"undoItems": [{
"afterImage": {
"rows": [{
"fields": [{
"name": "id",
"type": 4,
"value": 1
}, {
"name": "name",
"type": 12,
"value": "GTS"
}, {
"name": "since",
"type": 12,
"value": "2014"
}]
}],
"tableName": "product"
},
"beforeImage": {
"rows": [{
"fields": [{
"name": "id",
"type": 4,
"value": 1
}, {
"name": "name",
"type": 12,
"value": "TXC"
}, {
"name": "since",
"type": 12,
"value": "2014"
}]
}],
"tableName": "product"
},
"sqlType": "UPDATE"
}],
"xid": "xid:xxx"
}
1、提交前，向 TC 注册分支：申请 product 表中，主键值等于 1 的记录的 全局锁
2、本地事务提交：业务数据的更新和前面步骤中生成的 UNDO LOG 一并提交
3、将本地事务提交的结果上报给 TC
二阶段-回滚
1、收到 TC 的分支回滚请求，开启一个本地事务，执行如下操作
2、通过 XID 和 Branch ID 查找到相应的 UNDO LOG 记录
3、数据校验：拿 UNDO LOG 中的后镜与当前数据进行比较，如果有不同，说明数据被当前全局事务之外的动作做了修改。这种情况，需要根据配置策略来做处理，默认会有重试机制
4、根据 UNDO LOG 中的前镜像和业务 SQL 的相关信息生成并执行回滚的语句：
update product set name = 'TXC' where id = 1;
a、提交本地事务。并把本地事务的执行结果（即分支事务回滚的结果）上报给 TC
二阶段-提交
1、收到 TC 的分支提交请求，把请求放入一个异步任务的队列中，马上返回提交成功的结果给 TC
2、异步任务阶段的分支提交请求将异步和批量地删除相应 UNDO LOG 记录
浙公网安备 33010602011771号