@transactional 手动提交事务_记一次生产事务死锁问题引发服务雪崩与解决方案

1.项目背景

发生服务雪崩的项目是一个支付的核心服务,交易提现服务

2.项目发生现象

线程在执行过程中,会执行到某个方法的时候，就停止执行，日志也不打印。发生这个的时候，整个服务的所有执行操作都会停下来，导致整个服务不可用。

3.猜测

通过日志观察，所有的线程都是在要执行事务的时候会停下来不执行了。这个时候观察事物的使用方式。发生线程暂停的起止点的事务都是@Transactional(rollbackFor= Exception. class )嵌套 REQUIRES_NEW 事务，这两个事务嵌套的执行原理是父事务执行了，然后挂起事务去执行REQUIRES_NEW 子事务，子事务提交后，释放父事务然后提交父事务。等待是死锁的一个很关键的点。所以服务的雪崩一定和这个地方的事务使用有关

4.验证猜测

本地手动起并发执行@Transactional(rollbackFor= Exception. class )嵌套 REQUIRES_NEW 事务，当并发数达到20以上的时候，死锁的概率发生率近100%,，接着就是下一个问题了。为什么会发生事务死锁。事务的创建过程中是要提前去数据库申请数据库资源，这个时候问题又衍生到数据库的线程池配置了。
查看线程池配置，配置连接池配的1000，链接超时时间60秒，可是事务链接死锁60秒并未断开，查看检验发现链接池配置并未生效................

5.产生原因

连接池配置未生效，默认为8。导致并发嵌套事物的时候，外部创建完时候，执行子嵌套事务的事务，连接池数量不够等待连接池，外部又在等待内部事务提交，内部事务等待链接池。发生连接池一直占用死锁。导致整个服务的事务都创建等待服务雪崩

6.解决方法

手动装配连接池配置后并发死锁情况解决，死锁链接超时后自动断开链接释放连接池资源

也算是前同事留下来的一颗坑..................