因为JTA采用两阶段提交方式:
-
第一次是预备阶段
-
第二次才是正式提交
当第一次提交出现错误,则整个事务出现回滚,一个事务的时间可能会较长,因为它要跨越多个数据库多个数据资源的的操作,所以在性能上可能会造成吞吐量低。
那既然不使用 JTA,如何实现事务呢?
依次提交两事务:
-
start MQ transaction
-
receive message 读取消息
出错时,message transaction直接回滚
-
start DB transaction
-
update DB更新数据库
出错时,由于此时database transaction、message transaction都尚未提交,这时虽然已经读取了消息,但只要 MQ 支持事务功能,消息就会被回滚,重新放回MQ,重试重新触发该方法
- commit DB transaction
出错时,和上一点原因相同
- commit MQ transaction
出错时,database transaction已被提交了,所以无法回滚。MQ 事务尚未提交,所以可直接回滚。这也就是不使用 JTA 时遇到的最大难题。所以 spring 也提供了很多机制保障
消息放回至MQ队列,重试重新触发该方法
当这一步出现错误时,上面的因为已经commit,所以不会rollback
==============================================================================
1.start MQ transaction
2.receive message
针对 DB 使用 JTA 事务
3.start JTA transaction on DB
4.update DB
DB 一阶段提交
5.phase-1 commit on DB transaction
当该步出错时,由于DB 还在XA的第一次提交预备状态,DB 还是可以回滚
6.commit MQ transaction
等到 MQ 事务提交完成,才做 DB 二阶段提交
该步出错时,因为MQ不是XA方式,提交后无法回滚,虽然 DB 都可以回滚
7.phase-2 commit on DB transaction
适用场景
两个数据源可共享同一底层资源时。
比如ActiveMQ使用DB作为底层资源存储,使用DB的connection控制事务提交,需要数据源支持指定底层资源存储方式。
依次提交事务,可能会出错,尽量通过AOP或Listener实现事务直接的同步。
适用场景
其中一个数据源是MQ,并且事务由读MQ消息开始。
利用MQ消息的重试机制,重试的时候需要考虑重复消息。
1.start message transaction
2.receive message
3.start database transaction
数据库操作出错,消息会被放回MQ,重试重新触发该方法
4.update database
5.commit database transaction
6.commit message transaction
这种时候没有问题,都能成功回滚。
1.start message transaction
2.receive message
3.start database transaction
4.update database
最后
由于文案过于长,在此就不一一介绍了,这份Java后端架构进阶笔记内容包括:Java集合,JVM、Java并发、微服务、SpringNetty与 RPC 、网络、日志 、Zookeeper 、Kafka 、RabbitMQ 、Hbase 、MongoDB、Cassandra 、Java基础、负载均衡、数据库、一致性算法、Java算法、数据结构、分布式缓存等等知识详解。

本知识体系适合于所有Java程序员学习,关于以上目录中的知识点都有详细的讲解及介绍,掌握该知识点的所有内容对你会有一个质的提升,其中也总结了很多面试过程中遇到的题目以及有对应的视频解析总结。
知识体系适合于所有Java程序员学习,关于以上目录中的知识点都有详细的讲解及介绍,掌握该知识点的所有内容对你会有一个质的提升,其中也总结了很多面试过程中遇到的题目以及有对应的视频解析总结。
[外链图片转存中…(img-2H5EyEUd-1716356357864)]
[外链图片转存中…(img-LC6s648f-1716356357864)]