记一次数据库死锁

业务新上了一个功能,在发布的过程中,系统报出了数据库死锁异常:

com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction

死锁发生在一个事务中,事务对多个表进行了操作。在报错日志中,死锁发生在tableA与tableB。一开始怀疑此次发布的某个改动中对上面这两张表新增了select或update操作。将注意力用在排查这个问题上。排查后发现没有相关的变更,又猜测是否是由于更改造成并发请求进来,接口原来是有加分布式锁的,需求更改中缩小了分布式锁的粒度,确实是有可能造成并发请求。但很快又否定了,秒杀场景下的并发量尚且不会发生死锁,何况是这个接口?觉得问题应该别有所在。先回滚了需求后,联系dba执行了命令SHOW ENGINE INNODB STATUS将死锁日志拉取了出来:

从死锁日志可以看到事务(1)TRANSACTION尝试更新表A,等待表A的锁(1)WATING FOR THIS LOCK TO BE GRANTED.但此时另外一个事务(2)TRANSACTION已经持有了表A的锁:(2)HOLDS THE LOCK(S),同时也在等待表B的锁(2)WATING FOR THIS LOCK TO BE GRANTED. 情况可能如下所示:

事务(1) 事务(2)
持有表1的写锁,并更新了表1
等待表1的写锁
等待表2的写锁

由于事务2一直都获取不到表2的写锁,事务2无法提交,因此事务2持有的表1锁没有释放(在事务执行过程中,如果有加锁操作,这个锁需要等事务提交时释放),导致事务1一直在等待表1的写锁,从而最终导致死锁。那么表2的写锁被哪个事务持有了?有没有可能是事务1?也即是下面这种情况:

事务(1) 事务(2)
持有表2的写锁,并更新了表2
持有表1的写锁,并更新了表1
等待表1的写锁
等待表2的写锁

由于更新的是同一个用户的同一行记录,这种情况可能在sql执行顺序不一致所导致,所以对比了需求变更前后的事务逻辑,果然发现了端倪:

变更前:

事务开始
「
    更新表1
    更新表2
」
事务提交

变更后:

事务开始
「
    更新表2
    更新表1
」
事务提交

在发布的过程中,有部分机器的代码处于变更前,有部分机器的代码处于变更后,最终导致了上述的死锁问题。此时原因已经明了,但是疑惑的是为什么死锁出现时马上就报错,不会进行等待?查阅文档发现:死锁检测开了后,发生死锁会立马回滚。死锁检测关闭,锁等待超时时间这个设置才会生效:

posted @ 2019-04-04 09:09 melonstreet 阅读(...) 评论(...) 编辑 收藏