一、问题起因
2019-12-09 15:48:55 sentry收集到timed_task发生sql死锁异常日志。
二、排查过程
timed_task表是作为延时任务的记录表，本身是一个锁竞争环境不激烈的表，而且有统一的任务表操作流程且没有手动开启事务，所以这个死锁比较奇怪。
数据表结构
table `timed_task` (
`id` int ,
`biz_id` string,
`task_id` string,
`task_status` int,
`task_type` int,
PRIMARY KEY (`id`),
KEY `idx_biz_id` (`biz_id`),
KEY `idx_task_id` (`task_id`)
)
该表一共有3个索引，主键索引id；普通索引biz_id和task_id，我们先看下deadlock log。
deadlock log
死锁日志的内容已经很清楚的告诉我们是在哪个位置出现了死锁。
日志表明这2条sql存在锁循环等待的问题，我大概画了一下这2条sql的加锁顺序简图。
加锁顺序
1、sql1 对id为619364的记录进行加X锁；
2、sql2 根据二级索引idx_biz_id顺序的向下加X锁，同时对idx_task_id为空串的记录加X锁；
3、sql1 需要更新task_id，请求对idx_task_id 为空串的记录加X锁；
4、sql2 请求对主键索引id为619364的记录进行加X锁；
第3步与第4步发生了互相锁等待
好了，sql的死锁问题已经确定，那么现在就看下为什么会出现这种情况。
三、代码定位
我们对于延时队列的使用是单独封装了一个工具，除了该工具外部不会有其它的地方对该表进行操作。timed_task表操作流程如下：
该流程本身就存在一个问题，如果一个订单有相同的任务类型，会存在之前创建未触发的任务被取消的情况。
从死锁的sql上看，是同一时刻对订单的任务进行取消（第1步）和更新taskId操作（第4步），从任务的操作顺序上看这是不可能的。
起初怀疑创建任务被重复调用，由于是异步创建可能会出现并行的情况。排查了代码调用链，出现死锁的任务并未被重复调用，所以排除被重复调用的情况。
周末在家突然想到了一种可能，是不是其它的任务在处理的时候影响了这个任务呢？可能问题还是出在了延时任务的流程处理上，打开电脑看了下代码，确实存在这种可能。
//伪代码
//订单支付后，同时创建2个延时任务
void reminder(){
任务1：支付成功后提醒用户预约
createTask("xxxxx",8);
任务2：支付成功后套餐过期提醒
createTask("xxxxx",11);
}
这是调用创建延时任务的入口。
//伪代码
//异步的方式创建延时任务
@Async
void createTask(orderId,taskType){
//取消已存在的同类型任务
cancelExistTask(orderId,taskType);
//创建新任务
createTask(orderId,taskType);
}
创建任务处使用了@Async注解，开启新的线程处理，如果订单有多个类型的任务，就会出现同一订单多个不同任务并发的被创建，也存在任务互相被干扰的可能，我们继续看取消和创建方法。
//伪代码
//创建延时任务
boolean createTask(orderId,taskType){
//向任务表插入一条空的taskId的数据，任务状态为初始状态 1
insert into timed_task(biz_id,task_id,task_status) values(orderId,'',1);
//调用rpc服务申请taskId
String taskId = taskRpc.createTask(orderId,taskType);
//更新任务状态及taskId
update timed_task set task_id=taskId,task_status=2 where id=X;
return true;
}
创建任务顺序：
1、向任务表插入一条空的taskId的数据，任务状态为初始状态 1
2、申请taskId → 更新taskId和taskStatus
在看下取消任务的操作
//伪代码
//取消已存在的延时任务
boolean cancelTask(orderId,taskType){
//查询该订单所有未触发的任务（1：初始化；2：未触发）
List<Task> tasks = select * from timed_task where biz_id=orderId and task_status in (1,2);
//遍历所有已存在的任务，如果是当前类型进行取消操作
for(Task t : tasks){
if(t.taskType == taskType){
//调用rpc服务取消任务
taskRpc.cancelTask(orderId,taskType);
//更新任务状态，注意这里使用的条件
update timed_task set task_status=取消 where biz_id=orderId and task_status in (1,2) and task_id=xxx;
}
}
}
取消任务顺序：
1、根据订单号、taskStatus in (1,2)查询所有任务
2、遍历任务，如果taskType与传入的类型相同，则更新已存在的任务为取消
问题就是出在了更新任务的取消状态这一步，更新的时候没有使用主键更新，而是重复的使用了查询的条件并增加了taskId。
因为在更新的时候没有使用主键，而只使用了订单号、taskStatus in (1,2)、taskId 作为更新条件 ，如果其它任务此时刚刚插入timed_task表，还未更新taskId，就会被同时更新，更极端的情况就是出现死锁
总结：
这个死锁案例暴露了几个问题：
1、对于同一订单的任务操作建议不要使用并行
2、关于创建任务，可以先申请taskId，如果申请成功则入库，否则入库的数据最后成了垃圾数据
4、取消已存在任务应该根据订单号、任务类型、触发时间作为取消依据，否则会误取消应该执行的任务
5、更新timed_task任务表取消状态时，应该使用主键更新，减少锁的粒度
