Laravel 多进程数据库队列死锁分析及解决方案

问题描述

最近项目线上环境,队列服务器上一直频繁地大量出现数据库死锁问题,这个问题最早可以追溯到年前,19年的时候就出现了,当时一直频于开发业务功能,所以一直未去处理这个问题,这次正好来探究一下死锁的原因和问题所在。

首先,目前项目中使用的队列驱动选用的是database,因为简单、高效、无需扩展其他第三方应用,就一直采用了mysql数据库来作为队列驱动,线上队列环境运行的是:Ubuntu 16.04 + Mysql5.7 + Laravel5.6,这样的一个配置,目前整体使用supervisor在上面托管了16个队列进程。

上图显示了17个,因为有一个匹配符,所以需要-1,就是16个。

查看死锁日志

异常监控

这个死锁问题,接近触发了44万次事件,几乎每分每秒都有几率触发死锁,看了下队列源码发现是X锁造成的,然后下面就尝试模拟一下多进程队列消费,是否会造成死锁出现。

多进程消费队列

生成一个测试Job

通过artisan命令来生成,然后我们为了模拟处理过程,每个队列暂停了500毫秒。

<?php

namespace App\Jobs;

use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Bus\Dispatchable;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Queue\SerializesModels;

class TestJob implements ShouldQueue
{
    use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;

    /**
     * Create a new job instance.
     *
     * @return void
     */
    public function __construct()
    {
        //
    }

    /**
     * Execute the job.
     *
     * @return void
     */
    public function handle()
    {
        usleep(500000);
    }
}

生成10000个Job到数据库队列中

for($i=0;$i<10000;$i++){
    dispatch(new TestJob())->onQueue('test');
}

配置supervisor托管文件

我们这里使用supervisor来托管我们的8个处理进程,使用配置如下:

[program:laravel-worker-queue-test]
process_name=%(program_name)s_%(process_num)02d
command=php /data/sites/test/artisan queue:work --queue=test
autostart=true
autorestart=true
numprocs=8
user=root
redirect_stderr=true
stdout_logfile=/data/sites/test/storage/logs/worker.log

然后开始启动8个进程,进行测试。

然后发现,消费到1400+任务的时候,就产生了456次死锁。

下面我们就来分析一下死锁过程和尝试解决一些方案

求职机制(Get Job)

我们运行了8个进程,就相当于8名工作人员,他们都会进行 "求职操作",来获得下一个Job进行工作,在Laravel的源码中实现是这样的:

public function pop($queue = null)
{
    $queue = $this->getQueue($queue);

    return $this->database->transaction(function () use ($queue) {
        if ($job = $this->getNextAvailableJob($queue)) {
            return $this->marshalJob($queue, $job);
        }

        return null;
    });
}

转换成SQL语句就是如下操作:

BEGIN TRANSACTION;
SELECT * FROM `jobs` WHERE `queue` = ? AND ((`reserved_at` IS NULL and `available_at` <= NOW()) OR (`reserved_at` <= ?)) ORDER BY `id` ASC limit 1 FOR UPDATE; 
UPDATE `jobs` SET `reserved_at` = NOW(), `attempts` = `attempts` + 1 WHERE `id` = ?;
COMMIT;

第一个select查询,主要在进行获得下一个可用的job,如果available_at < now，这表示该作业可用,然后选择了for update增加了排它锁,禁止其他工作人员(worker进程),进行处理货货更新。

第二个update更新,工作人员(worker进程)将会更新reserved_at时间,进行保留,让其他工作进程无法再查询到，同时reserved_at字段将会保障,每个job在删除之前,至少将被执行一次(除了attempts太大,满足删除条件)。

当执行完第二个update操作后,工作人员(worker进程)将会开始处理队列作业,处理完成后,中途没有异常后,工作人员就会开始删除掉该作业。

laravel代码如下:

public function deleteReserved($queue, $id)
{
    $this->database->transaction(function () use ($id) {
        if ($this->database->table($this->table)->lockForUpdate()->find($id)) {
            $this->database->table($this->table)->where('id', $id)->delete();
        }
    });
}

转换成对应的SQL操作:

BEGIN TRANSACTION;
SELECT * from `jobs` WHERE `id` = ? FOR UPDATE;
DELETE FROM `jobs` WHERE `id` = ?;
COMMIT;

首先还是会尝试去使用X锁,锁住该记录,然后进行删除,再提交整个事务。

这样问题就开始来了,通过以上结构,单个进程进行该操作应该没有太大问题,但是多个进程同时操作执行2组SQL的时候,可能就会出现死锁了。

当同时8个进程进行该操作时,同时线上又在频繁的操作该表,这边又在频繁的删改查,可以算得上并发式的疯狗操作。

问题原因

当工作进程(1)正在查询下一个可用工作进程时,他将会通过for update尝试锁住主键索引(id_index)

工厂进程(2)也刚处理完一个作业,并且正在尝试执行删除查询,以便从该表中删除作业,当可以执行删除时,已经拿到了主键锁(index lock),但是删除操作又会影响到queue_index,因此查询就会请求该锁。

这样将会可能产生全局死锁,每个事务都在等待另一个事务持有的锁。

下面是用脚本模拟整个队列的操作流程,依然产生了大量的死锁:

解决方案

根据以上的问题,想到了一些解决方案,仍然可以有效处理掉死锁：

1.切换到队列系统到Redis或Beanstalkd,减少Mysql层面的事务开销,利用内存达到更快的处理速度。

2.删除掉queue_index索引,为了避免死锁,我们可以删除这个条件,但是删除后,处理速度会大大降低。

3.添加软删除:deleted_at,将数据变成更新操作,而不是删除操作,由于是更新,所以不会导致死锁(无需锁定该记录)

4.尝试使用第三方扩展包laravel-queue-database-ph4,使用S锁实现的数据库队列,增加了version字段,消除掉了死锁的问题。