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

来到golang学习网的大家，相信都是编程学习爱好者，希望在这里学习数据库相关编程知识。下面本篇文章就来带大家聊聊《Laravel 多进程数据库队列死锁分析及解决方案》，介绍一下MySQL、队列、死锁、PHP、laravel，希望对大家的知识积累有所帮助，助力实战开发！

问题描述

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

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

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

查看死锁日志

异常监控

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

多进程消费队列

生成一个测试Job

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

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

for($i=0;$ionQueue('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` 

第一个select查询,主要在进行获得下一个可用的job,如果

available_at ，这表示该作业可用,然后选择了
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字段,消除掉了死锁的问题。

本篇关于《Laravel 多进程数据库队列死锁分析及解决方案》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于数据库的相关知识，请关注golang学习网公众号！