Spring事务对所有方法全局开启的潜在问题

本文探讨了Spring全局开启事务可能导致的DB通信次数增加、系统响应效率降低、数据库连接数增加等问题。分析了不必要的事务开启场景,并给出了优化建议,强调了精细化控制事务的重要性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Spring 事务管理器基于AOP切入方法来实现的,开发人员可以使用XML配置,也可以使用Annotation来标记具体的方法,可能有的开发人员为了简单省事,就讲AOP切入的方法定义成所有方法,那么写代码就简单了,这样做到底有没有问题呢?肯定有,有兴趣的开发者可以一起探讨下:

 

应用于DB之间的通信次数增加了几次,1次?2次?3次?....

增加事务操作后,通信次数自然会变多,通信次数变多导致的直接问题都有那些呢:

  • 通信次数变多,对于系统大并发场景下,应用访问DB的延迟会倍增,业务延迟变大,同时连接占用时间变长会导致整体DB连接数增加
  • 对于应用与DB之间延迟较大的场景,会在通信次数上倍增,例如0.02ms的延迟增加1次没什么感觉,5ms的延迟增加1次就有点变化了,200ms延迟增加1次就会比较明显,如果开启事务增加的延迟不止一次,那么会被进一步放大

Spring AOP事务处理中,对普通的事务处理步骤为:

步骤 Spring操作Connection的动作 MySQL JDBC实际操作 增加数据库通信次数

开启事务(Begin)

setAutoCommit(false) set autommit=0; 1
执行SQL 多条SQL逐步执行 -- 0

提交或回滚事务

 

commit()/rollback() commit; rollback; 1
恢复连接自动提交状态 setAutoCommit(true) set autocommit=1 1

也就是会增加3次数据库通信操作,如果所有的操作都开启事务,相信业务中大量的数据库操作都是简单、单行类操作较多,那么事务的通信次数可能会达到本身业务的3倍,整体有可能在最坏情况会被放大4倍。例如原本2ms的操作可能会变成8ms,原本100ms可以完成的操作400ms。

而这不并是最坏的情况,有的开发者为了达到某些业务目标,开启Spring事务的同时,还开启了只读事务(就只读事务在业务的应用会在其他文章中展开,本文只讨论只读事务会增加的操作):

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值