Seata分布式事务冲突

Question

前提:

1. 服务均引用了全局异常处理 @RestControllerAdvice
2. 服务均引用了Seata来管理分布式事务
3. feign调用
4. 调用流程: content-center(A) 调用 user-center(B)的加分接口

第一轮测试:

1. 测试1:A抛异常B正常: B依旧正常运行未回滚
2. 测试2:A正常B抛异常(全局异常捕获处理正常返回): A正常执行未回滚

引入官方的解决方案:

通过AOP动态创建/关闭Seata分布式事务.

第二轮测试:

1. 测试1.AB都加入AOP或B单独加AOP: A一直报 xid count not found, …mybe finished
2. 测试2-1.A单独加AOP: A抛异常B正常: 事务OK
3. 测试2-1.A单独加AOP: A正常B抛异常(全局异常捕获处理正常返回): A正常执行未回滚
4. 测试3:A单独加,且A中必须嵌入代码获取B的返回值,根据code!=200自己抛异常…无论谁抛异常,事务都OK了

问题与意愿:

1. 全局异常捕获了,子服务不抛异常,seata就没法识别回滚了吗?老师有没有可以推荐的链接让我学习学习…目前只能使用第二轮的测试3这个笨办法.
2. 全局异常需要统一在gateway实现嘛…感觉别个都没这样弄呢
3. 老师能出个进阶教程吗.现在很多都在用seata,没用rocketmq吧.实在不知道去那儿学习啊.

Answer 1

大目 2022-03-15 17:43:32

不太清楚哦，会不会是seata使用层面的问题哈？

• 提问者 wa小艾 #1

  老师都2022年了.说好的去年8月有个进阶的版本呀~~~来个seata最佳使用方案嘛

• 大目 回复 提问者 wa小艾 #2

  一直没有时间搞；
  同时我对分布式事务的观点也有了变化。
  现在业界分布式事务更多的项目选择放弃，或者人工介入。
  
  主要原因是：线上99.99%的业务都是正常运行的，只有0.01%可能存在数据不一致的问题；
  而引入seata之类的分布式事务中间件后，却有100%的请求性能会下降。这笔生意不太划算。
  
  也是因为这个，目前据我调研，只有一些金融系的项目才会上seata。
  包括阿里内部，多数项目其实也没有上分布式事务中间件。。