本文主要是介绍大事务问题场景与应对之策，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
先来说说大事务问题是什么
- 如果锁定的资源多，容易造成大量的死锁和锁超时
eg：下单接口正常耗时是100ms，理论上支持10tps，但是有一个请求因其他原因导致耗时10s，这时很多其他请求就会锁超时
- 如果事务回滚则会占用大量存储空间，同样回滚所需要的时间也会变长
因为回滚日志只有在不需要的时候才会删除，事务没提交时不能被删除
- 执行时间长，主从延迟
目前mysql的架构就是主从，代码查基本都改造成从节点，如果有大事务问题，这点尤为明显
应对之策
- 代码中尽量避免在没必要的地方使用@Transactional
仅做查询的地方就不需要加，注解覆盖的方法尽可能的粒度要小
- 事务中避免远程调用
1. 将远程调用的动作尽可能的放在事务外去操作
2. 如果因业务流程，没办法将远程调用的操作放到事务外，那么应该严格控制远程调用的 连接时间 读取时间等几个配置
- 非手动事务执行
1. 这点在第一点其实有表明一些，降低事务的粒度
2. 一些对数据准确性要求没那么高的可以不放事务中执行
- 非必要不加锁
首先加锁相对不加是要更费时的，而且很多业务分析下来可能没有什么并发，可以使用version版本号来操作
- 异步处理
可以抽出去不放在事务中的可以使用异步，但是要分析数据一致性的问题
- 避免使用事务一次性处理太多数据
特别是连接资源紧张时，此操作影响尤为明显，因数据库连接一直占用是不会主动放开的（题外话：cpu调度策略可以看看，这里连接则对应FIFO，先到先拿数据库连接），所以我们尽可能的少量多次去执行，这样整体可能会更优（需要根据实际情况分析）
这篇关于大事务问题场景与应对之策的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
