问题描述
最近项目线上环境,队列服务器上一直频繁地大量出现数据库死锁问题,这个问题最早可以追溯到年前,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字段,消除掉了死锁的问题。
