记一次大事务导致的数据库死锁引起线上服务器load飙升的故障

一、背景描述

公司业务系统由多个语言开发，核心业务由.net团队支持，数据存储在sqlServer中，为了使用这些数据由JAVA团队在上层做一个数据聚合平台，创建了个职责单一的新应用来做数据转换，同步到底层mysql数据库中，对外提供了一个标准接口由业务方通过定时任务分批同步，支持一次传输多条数据，数据同步策略是每秒6个线程并发同步5条记录，同步失败会在1，2，4s内重试三次

二、故障现场

第一次

故障现象： api层服务异常日志告警，同步数据服务dubbo服务超时5s，但是业务应用中没有任何异常日志，跟业务方确认告警时间刚好是同步任务刚开启的时候
排查分析： 业务应用服务器load略微有点上升，没有发生OOM，数据库连接数增加了几个，业务应用无异常日志，但是超时日志比较多，大概都在15-20s之间。数据库连接数只增加了几个，跟配置的连接数不符合，排查代码发现连接池配置没有生效，全部走的默认配置，怀疑是大量请求进来初始化连接数过慢，然后线程一直阻塞等待数据库连接造成的超时。
初步结论： 数据库连接池配置没有生效，采用默认初始化连接数0，最大连接数8，任务刚启动进来大量请求初始化连接数比较少导致大量阻塞
不要慌，进行技术性调整：修改连接池配置使其生效，默认初始化20个连接数，最大50个

spring.datasource.druid.initial-size=20
spring.datasource.druid.max-active=50
spring.datasource.druid.min-idle=20
spring.datasource.druid.max-wait=500

在第一次同步任务结束之后，发布了上面的修改内容，之后等待下一次任务启动，观察是否解决

第二次

故障现象： 同步任务启动之后，api层开始出现大量服务超时的告警，同时业务应用开始出现load飙升的告警，以及大量的超时日志（有大量50s的超时）和异常日志，双核机器平均负载一下子到了30，CPU百分百的使用率，触目惊心，服务器指标如下，可以看到在10点的时候各项指标都一路飙升，服务器负载到达顶点持续一段时间之后，又下落恢复正常

业务应用异常日志归类为下面三种：

<