大事务问题场景与应对之策

发布时间:2024年01月22日

先来说说大事务问题是什么

  • 如果锁定的资源多,容易造成大量的死锁和锁超时

????????????????eg:下单接口正常耗时是100ms,理论上支持10tps,但是有一个请求因其他原因导致耗时10s,这时很多其他请求就会锁超时

  • 如果事务回滚则会占用大量存储空间,同样回滚所需要的时间也会变长

????????????????因为回滚日志只有在不需要的时候才会删除,事务没提交时不能被删除

  • 执行时间长,主从延迟

????????????????目前mysql的架构就是主从,代码查基本都改造成从节点,如果有大事务问题,这点尤为明显


应对之策

  • 代码中尽量避免在没必要的地方使用@Transactional

? ? ? ? ? ? ? ? 仅做查询的地方就不需要加,注解覆盖的方法尽可能的粒度要小

  • 事务中避免远程调用

? ? ? ? ? ? ? ? 1. 将远程调用的动作尽可能的放在事务外去操作
? ? ? ? ? ? ? ? 2. 如果因业务流程,没办法将远程调用的操作放到事务外,那么应该严格控制远程调用的 连接时间 读取时间等几个配置

  • 非手动事务执行

? ? ? ? ? ? ? ? 1. 这点在第一点其实有表明一些,降低事务的粒度
? ? ? ? ? ? ? ? 2. 一些对数据准确性要求没那么高的可以不放事务中执行

  • 非必要不加锁

????????????????首先加锁相对不加是要更费时的,而且很多业务分析下来可能没有什么并发,可以使用version版本号来操作

  • 异步处理

????????????????可以抽出去不放在事务中的可以使用异步,但是要分析数据一致性的问题

  • 避免使用事务一次性处理太多数据

? ? ? ????????特别是连接资源紧张时,此操作影响尤为明显,因数据库连接一直占用是不会主动放开的(题外话:cpu调度策略可以看看,这里连接则对应FIFO,先到先拿数据库连接),所以我们尽可能的少量多次去执行,这样整体可能会更优(需要根据实际情况分析)

文章来源:https://blog.csdn.net/weixin_44700876/article/details/135659417
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。