一、问题起因

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

死锁日志的内容已经很清楚的告诉我们是在哪个位置出现了死锁。

1576921873333.jpg

日志表明这2条sql存在锁循环等待的问题，我大概画了一下这2条sql的加锁顺序简图。

加锁顺序

截屏2019-12-21下午5.34.26.png

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表操作流程如下：

截屏2019-12-21下午6.37.35.png

该流程本身就存在一个问题，如果一个订单有相同的任务类型，会存在之前创建未触发的任务被取消的情况。

从死锁的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 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任务表取消状态时，应该使用主键更新，减少锁的粒度

sql死锁排查一