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字段,消除掉了死锁的问题。