项目一次数据库死锁排查分析

秒速五厘米 2022-02-28 15:42 260阅读 0赞

一日线上系统抛出`lock wait timeout exceeded; try restarting transaction`异常信息，很是惊恐，遂放下手头事务，优先解决。随后发现事务的使用不规范，真的是事务不规范，线上两行泪。分析如下：

try{
    	代码1
    	开启事务
    	代码2
    	提交事务
    	代码3
    	返回信息 1
    }catch(Exception e){
    	代码4
    	回滚事务
    	代码5
    返回信息 2
    }

分析  
条件: 代码1 抛出异常，在回滚事务的时候，“事务不存在”,所以建议如果代码1不会有异常就放到try外部，如果有异常，合并到代码2。  
条件: 代码2 抛出异常 能够正常处理  
条件: 代码3 抛出异常 事务已经提交，会抛出“事务不存在”  
条件: 代码4 抛出异常 事务已经提交，会抛出“事务不存在”  
条件: 代码5 异常抛给调用者

组合条件：  
代码1、4异常 异常抛给调用者  
代码2、4异常 事务开启无提交、无回滚，数据库一直等待事务的结束，表现界面卡死，抛出数据库locked异常，因为再次开启事务的时候，此表已经存在锁（写锁或排它锁），无法再加锁。  
代码2、5异常，事务已经回滚，抛出代码5的异常  
代码3、4异常，抛出4的异常

很明显存在bug，所以总结如下：  
代码1拆分，没有异常的放到try外部，有异常，不影响事务的另外写try…catch处理，影响事务的当然要放到代码2处。  
代码3处理，如果是必须执行的，方进finally，如果不是放到try…catch外部执行。  
代码4处理，合并进代码5

整理过后的结构如下

代码1
    try{
    	开启事务
    	代码2
    	提交事务
    	
    }catch(Exception e){
    	回滚事务
    	代码3
    	打印异常信息
    	返回信息 1
    }finally{
    	代码4
    }
    代码5
    返回信息 2

代码1：不影响事务的业务代码  
代码2：事务的业务逻辑代码  
代码3：异常处理逻辑  
代码4：必须执行的代码（关闭IO流等操作）  
代码5,：其他操作