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

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

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

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

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

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

• 执行时间长，主从延迟

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

应对之策

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

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

• 事务中避免远程调用

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

• 非手动事务执行

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

• 非必要不加锁

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

• 异步处理

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

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

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