官网

https://seata.io/zh-cn/docs/overview/what-is-seata.html

seata建表语句
https://gitee.com/dhb414/seata/blob/master/script/server/db/mysql.sql

undo_log https://gitee.com/dhb414/seata/blob/master/script/client/at/db/mysql.sql

配置：

#阿里分布式事务配置
seata:
  service:
    vgroup-mapping:
      #这里的组名my_test_tx_group就是上面已经配置过的
      # seata-server 对应的就是register.conf里的application选项的内容
      my_test_tx_group1: seata-server
    grouplist:
      #这里对应的就是上面的seata-server，后面的蚕食seata服务的IP地址和端口号
      seata-server: l27.0.0.1:9091
    enable-degrade: false
    disable-global-transaction: false

Demo模型

排坑

mysql-connector-java不能用5.1.47，这个版本有bug，以前不会触发，使用seata后会触发

undo_log滞留的问题

AT模式自测用例

异步调用的4种情况：

1、主事务调用分支事务之前；2、主事务和分支事务均未结束；3、分支事务结束而主事务没结束；4、主事务结束而分支事务没结束；

异步调用出问题的两种情况：

1、主事务成功，分支事务失败；

2、主事务失败，分支事务成功；

一TM一RM，Feign方式（同步）

同步调用的3个阶段：1、主事务调用分支事务之前；2、分支事务结束并返回之前；3、分支事务提交后，且主事务提交前

同步调用出问题的情况：

1、主事务成功，分支事务失败（主事务捕获掉异常）

2、主事务失败，分支事务成功

正常执行

观察每个阶段的undo_log和TC的记录

阶段一：只有TC全局事务注册

阶段二：只有TC的全局事务表有记录

阶段二（主事务没有使用@Transactional(rollbackFor = Exception.class)）：主事务提交，主事务undo存在；分支事务啥都没有；TC全局事务有，锁了主事务，分支事务表注册了主事务

阶段二附加：接阶段二，分支一直断点，主事务会超时而失败，此时TC的全局事务也没有了。等到分支断点放开，分支提交也会因为没有全局事务而失败

阶段二附加（主事务没有使用@Transactional(rollbackFor = Exception.class)）：主事务超时失败了，并且发生回滚，全局事务也会回滚，但此时分支事务处于断点，放开断点后分支事务提交时，发现没有全局事务，分支事务也会回滚

阶段三：主事务已提交有undolog；分支事务已提交有undolog；TC全局事务一个，全局锁两个，分支事务注册两个

观察最终结果是否正确

全部符合预期

主事务成功，分支事务失败（主事务捕获掉异常）

观察每个阶段的undo_log和TC的记录

观察最终效果是否正确

seata认为，主事务捕获异常代表不关心分支事务，所以主事务正常提交

分支事务由于发生异常，没有正常提交

主事务失败，分支事务成功

观察每个阶段的undo_log和TC的记录

处于阶段三时：跟正常执行的阶段三相同

观察最终效果是否正确

所有分支均回滚

Seata尝试及源码拜读

原文：https://www.cnblogs.com/anhaogoon/p/13033986.html