XA

理解

第一步是@GlobalTransactional在方法入口通知TM事务管理器发送全局事务的范围给TC事务协调者开启事务

开启事务后第二步是调用各分支去TC事务协调中去注册分支的事务

第三步是微服务去执行相对应的sql

比如我订单对应的是库存跟支付 那么就是库存跟支付去执行自己的sql语句

执行完了之后是向TC事务协调者汇报事务的状态

然后TC事务协调者会根据各分支汇报的情况去选择全局提交或者全局回滚

然后根据选择的结果通知给RM资源管理器 去处理各分支的提交或者回滚

疑问 第二阶段为什么是由TM事务管理器去发起的提交 不应该是TC接收到所有RM的结果汇报了之后自己去检查判断吗 为什么要有2.1

还是说TM能感知到所有事务完毕了 然后发起询问请求TC 然后TC再根据结果去通知RM呢

优缺点很好理解

保证事务所有一致性的前提下肯定是牺牲了可用性跟性能

因为要保证事务的所有一致性肯定就是要将事务经过的地方都锁起来

所以这个时候别人要访问修改都得排队 要等到全局事务的提交或者回滚才能释放数据库资源

而且还要依赖关系型数据库 因为关系型数据库才有事务

所以我觉得应该不咋用 性价比不高

AT模式
AT模式同样是分阶段提交的事务模型，不过缺弥补了XA模型中资源锁定周期过长的缺陷。

那么如何解决锁定资源周期过长的缺陷呢

那无非就是不要等到全局事务的提交或者回滚才能释放资源

这个时候就可以采用类似redis那种快照版本

记录当前的版本的快照 如果提交 删除快照 因为提交了就不用回滚到之前的版本了

如果全局事务回滚的话 那就是根据快照的版本恢复到事务执行之前的数据就ok了

注意 快照一定是在执行sql语句之前就已经保存下来的

AT与XA的区别

简述AT模式与XA模式最大的区别是什么？

• XA模式一阶段不提交事务，锁定资源；AT模式一阶段直接提交，不锁定资源。

• XA模式依赖数据库机制实现回滚；AT模式利用数据快照实现数据回滚。

• XA模式强一致；AT模式最终一致

所谓强一致就是从头到尾 各微服务的事务状态都保持一致

最终一致则是最后的结果一致 过程不一定一致

优缺点

AT模式的优点：

• 一阶段完成直接提交事务，释放数据库资源，性能比较好

• 利用全局锁实现读写隔离

• 没有代码侵入，框架自动完成回滚和提交

AT模式的缺点：

• 两阶段之间属于软状态，属于最终一致

• 框架的快照功能会影响性能，但比XA模式要好很多