最近在研究seata的AT模式，先在本地搭建了一个演示demo，看看seata是如何使用的。在网上搜的demo，配置相对来说都比较多。我最终搭建的版本，配置较少，所以写篇文章分享下，希望能帮到对seata感兴趣的小伙伴。先看下文章目录

1、AT模式架构图

我从官网上拷贝了一张图，先看一下seata AT模式的整体架构

从图上，一共看到5个服务
1)、TC：事务协调者，负责全局事务的管理，以及各分支事务的管理

2)、Business：业务聚合服务，比如下单服务。在下单服务中，会依赖很多上游服务，比如图中的库存服务、订单服务、账户服务等

3)、Storage：库存服务

4)、Account：账户服务

5)、Order：订单服务

2、演示微服务搭建

2.1、demo源码获取

我把演示demo的代码上传到了码云，可以从码云上将项目下载下来，在本地部署
项目地址
依次启动OrderService、StorageService、AccountService、seataProject这4个项目

2.2、项目配置改动

2.2.1、执行scripts中的脚本

以AccountService项目举例，其他3个项目一样
account_tbl.sql
undo_log.sql

2.2.2、修改数据库的连接

如果你的这几个项目对应的数据库端口和我项目里不一致，需要改下

2.2.3、修改注册中心

如果你不想用zookeeper，那这里也需要修改一下

3、seata server服务搭建

其实没啥可搭建的，开箱即用。seata server下载地址
启动命令如下。如果想改端口运行，可以加-p参数或者修改conf目录中的application.yml文件

sh seata-server.sh -h 127.0.0.1 -m file

4、验证

如果你没改动端口，直接访问
http://127.0.0.1:6099/business/commit?userId=2&commodityCode=1&orderCount=2，即可触发下单异常，我在OrderService的微服务中写死了一段测试代码，userId=2时，触发一个异常，然后触发事务回滚
此时可以在TM、RM处看到事务提交以及回滚的日志

4.1、事务成功提交

TM提交事务日志

//1、开启一个全局事务,事务id: 0.0.1.1:8099:6224557381237174277
o.a.s.tm.api.DefaultGlobalTransaction    : Begin new global transaction [0.0.1.1:8099:6224557381237174277]

//2、准备提交事务
o.a.s.tm.api.DefaultGlobalTransaction    : transaction 0.0.1.1:8099:6224557381237174277 will be commit

//3、事务提交结束
o.a.s.tm.api.DefaultGlobalTransaction    : transaction end, xid = 0.0.1.1:8099:6224557381237174277

//4、事务已提交
o.a.s.tm.api.DefaultGlobalTransaction    : [0.0.1.1:8099:6224557381237174277] commit status: Committed

RM提交事务日志

//1、注册分支事务成功,分支事务id:6224557381237174279; 全局事务id: 0.0.1.1:8099:6224557381237174277
o.a.seata.rm.AbstractResourceManager     : branch register success, xid:0.0.1.1:8099:6224557381237174277, branchId:6224557381237174279, lockKeys:account_tbl:1

//2、提交分支事务
o.a.s.c.r.p.c.RmBranchCommitProcessor    : rm client handle branch commit process:BranchCommitRequest{xid='0.0.1.1:8099:6224557381237174277', branchId=6224557381237174279, branchType=AT, resourceId='jdbc:mysql://127.0.0.1:3310/seata-account', applicationData='null'}

//3、分支事务提交中
org.apache.seata.rm.AbstractRMHandler    : Branch committing: 0.0.1.1:8099:6224557381237174277 6224557381237174279 jdbc:mysql://127.0.0.1:3310/seata-account null

//4、分支事务提交成功
org.apache.seata.rm.AbstractRMHandler    : Branch commit result: PhaseTwo_Committed

然后可以看下三张表(库存、订单、账户)的数据是否保持一致

4.2、事务回滚

手动制造一个提交异常，然后看TM以及AM的日志

TM回滚事务日志

//1、开启一个全局事务,事务id: 0.0.1.1:8099:6224557381237174273
o.a.s.tm.api.DefaultGlobalTransaction    : Begin new global transaction [0.0.1.1:8099:6224557381237174273]

//2、事务将要回滚
o.a.s.tm.api.DefaultGlobalTransaction    : transaction 0.0.1.1:8099:6224557381237174273 will be rollback

//3、事务回滚结束
o.a.s.tm.api.DefaultGlobalTransaction    : transaction end, xid = 0.0.1.1:8099:6224557381237174273

//4、事务已回滚
o.a.s.tm.api.DefaultGlobalTransaction    : [0.0.1.1:8099:6224557381237174273] rollback status: Rollbacked

RM回滚事务日志

//1、注册分支事务，分支事务id:6224557381237174275; 全局事务id: 0.0.1.1:8099:6224557381237174273
o.a.seata.rm.AbstractResourceManager     : branch register success, xid:0.0.1.1:8099:6224557381237174273, branchId:6224557381237174275, lockKeys:account_tbl:2

//2、分支事务回滚,回滚要依赖undo_log日志
o.a.s.c.r.p.c.RmBranchRollbackProcessor  : rm handle branch rollback process:BranchRollbackRequest{xid='0.0.1.1:8099:6224557381237174273', branchId=6224557381237174275, branchType=AT, resourceId='jdbc:mysql://127.0.0.1:3310/seata-account', applicationData='null'}

//3、分支事务回滚中
org.apache.seata.rm.AbstractRMHandler    : Branch Rollbacking: 0.0.1.1:8099:6224557381237174273 6224557381237174275 jdbc:mysql://127.0.0.1:3310/seata-account

//4、回滚完成,删除undo_log
o.a.s.r.d.undo.AbstractUndoLogManager    : xid 0.0.1.1:8099:6224557381237174273 branch 6224557381237174275, undo_log deleted with GlobalFinished

//5、分支事务回滚成功
o.a.s.rm.datasource.DataSourceManager    : branch rollback success, xid:0.0.1.1:8099:6224557381237174273, branchId:6224557381237174275

//6、分支事务回滚结果.二阶段回滚
org.apache.seata.rm.AbstractRMHandler    : Branch Rollbacked result: PhaseTwo_Rollbacked

再次看下三张表的数据，如果事务回滚成功，数据是没有变化的，不会发生修改或者新增
最后看下undo_log表，应该是无数据，但是Auto_Increment的值已经变成了2，证明undo_log中新增过一条数据，然后又被删除了。这印证了，事务回滚会利用到undo_log，回滚完成，就删除undo_log