线上死锁分析解决纪实
date
May 17, 2019
slug
record-of-deadlock-analytics
status
Published
tags
Dev
summary
服务发生死锁，死锁检测时间较长，31s后死锁检测出来事务才得以回滚，期间不断有相同请求进来，造成死锁越来越复杂，并且服务端线程池中的所有线程都在等待锁，最后造成服务端线程池无空闲线程，拒绝服务。
type
Post
服务发生死锁，死锁检测时间较长，31s后死锁检测出来事务才得以回滚，期间不断有相同请求进来，造成死锁越来越复杂，并且服务端线程池中的所有线程都在等待锁，最后造成服务端线程池无空闲线程，拒绝服务。
注意：单条 SQL 也是一个事务，也会和其他事务发生死锁。
原因分析
首先奉上 InnoDB 日志 和 DDL
如果看不懂日志，可以参考 这个文章
我们先来看看 事务1 和事务2 分别持有什么锁，又在等待什么锁。由于日志是在事务 1 的角度来打印的，所以我们只能看到事务 2 持有
lock_mode X locks rec but not gap 锁，在等待 lock_mode X locks gap before rec insert intention 锁。lock_mode X locks rec but not gap 就是写记录锁，只锁了单条记录。lock_mode X locks gap before rec insert intention就是一个插入意向锁，目标是在对应的间隙上（不包括记录本身）加锁。
通过事务 2 的锁信息我们可以推测出事务 1 的锁持有信息，因此就有了下面的图。
事务 1 当前拥有的应该是间隙 A 和 记录X 组成的 nexy-key 锁 ，现在正在等待的是间隙 b 的锁。
事务 2 当前拥有的应该是 记录 Y 的 X锁， 间隙 D 的插入意向锁， 间隙 C 的插入意向锁 ，现在正在等待的是间隙 e 的 间隙插入意向锁（也有可能是 记录 Y 的 record lock）。
由于 next-key 锁 和 插入意向锁互斥，所以事务 1 在等待事务 2 释放 C, Y, D；事务 2 在等待事务 1 释放 A。 这样看来正好符合 InnoDB 中的 log。
模拟流程
个人认为 由于 next-key 锁和 Gap 锁不是一种锁，因此必然存在时间差，这种时间差在并发量很大的情况下才会凸显出来。
事务1 | 事务2 |
ㅤ | INSERT INTO campaignmockqueue 记录 Y |
DELETE FROM campaignmockqueue 获取了 A 的间隙锁还没获取 next-key 锁 | ㅤ |
ㅤ | INSERT INTO campaignmockqueue(campaignid, addtime )VALUES (52327709, 1557992297) , (52327709, 1559383140), (52327709, 1557992296) （阻塞） |
DELETE FROM campaignmockqueue 获取 next-key 锁 （阻塞） | ㅤ |
验证猜想
上面的情况仅仅是推测，如果我们能拿到 INSERT 语句角度的死锁日志就好了。搜寻了一下 InnoDB 日志，得到了下面的日志，通过交叉分析，可以验证了我们的猜想。
解决方案
DELETE FROM
campaignmockqueue 不使用 idx_campid 这个索引加锁，而使用唯一主键来做操作，和 insert 操作使用不同的索引，来避免这个问题。