Laravel 11 结合php-enqueue RabbitMQ Worker重启后批次任务无法继续执行的问题求助

云上老周

2026-4-7

大家好，我这边遇到一个挺头疼的问题，想请教下社区的各位大佬：

我们在Laravel 11系统中使用php-enqueue的RabbitMQ Worker处理批次任务。每个任务执行完成后，会检查当前批次是否需要添加新任务——如果需要就追加到批次中，不需要的话就触发批次的then/finally钩子。

为了避免Worker长时间运行引发内存泄漏等问题，我们通过自定义Service Provider给Worker配置了自动重启机制：当环境变量RABBITMQ_RESTART_AFTER_JOBS设置有效值后，每处理指定数量的任务就自动重启Worker。对应的实现代码如下：

$this->app->extend('queue.worker', function ($worker, $app) {
    $extensions = [
        new SignalExtension,
        new LoggerExtension(Log::getLogger()),
    ];

    $maxJobs = (int) config('queue.connections.rabbitmq.restart_after_jobs');
    if ($maxJobs > 0) {
        Log::info("Automatic restart after jobs provided via RABBITMQ_RESTART_AFTER_JOBS: restarting every $maxJobs jobs.");
        $extensions[] = new LimitConsumedMessagesExtension($maxJobs);
    } else {
        Log::warning('NO automatic after jobs provided via RABBITMQ_RESTART_AFTER_JOBS');
    }

    return (new Worker(
        $app['queue'],
        $app['events'],
        $app[ExceptionHandler::class],
        function () use ($app) {
            return $app->isDownForMaintenance();
        }
    ))->setExtensions($extensions);
});

但现在遇到了一个奇怪的异常场景：每当Worker触发自动重启时，经常会出现这样的情况——新任务确实被成功添加到批次中（数据库的batches表里能查到对应记录），但这个批次后续的所有任务再也不会被任何Worker处理了。

下面是我们捕获到的一段相关日志示例：

2025-08-12 07:40:36.452 new batch made 9f9d54ef-357f-4b3f-bb4a-d4b239fbc788
2025-08-12 07:40:36.561 new job added to batch 9f9d54ef-357f-4b3f-bb4a-d4b239fbc788
2025-08-12 07:40:36.563 [Job] Acknowledging message.
2025-08-12 07:40:36.564 [Queue] Pushing new job
2025-08-12 07:40:36.566 [Worker] Job result processed {"job_id":null,"result":"enqueue.already_acknowledged"}
2025-08-12 07:40:36.567 [Worker] Finished processing job.
2025-08-12 07:40:36.568 [SignalExtension] Interrupt execution

补充几个环境细节供大家参考：

我们的任务是按不同队列划分执行的，不确定这个因素是否会产生影响；
用Supervisor管控队列Worker，配置如下：

[supervisord]
nodaemon=true
user=root
logfile=/dev/stdout
logfile_maxbytes = 0
pidfile=/var/run/supervisord.pid

[program:core-worker]
command=/usr/local/bin/php -d variables_order=EGPCS /var/www/html/artisan queue:work --backoff=0 --max-jobs=0 --memory=256 --sleep=3 --timeout=21600 --tries=1 --rest=0
process_name=%(program_name)s_%(process_num)02d
numprocs=15
stopwaitsecs=21600
autostart=true
autorestart=true
stopasgroup=true
killasgroup=true
stderr_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0

Laravel的RabbitMQ队列配置：

'rabbitmq' => [
    'driver' => 'interop',
    'dsn' => 'amqp+rabbitmq://' . env('RABBITMQ_USER') . ':' . env('RABBITMQ_PASSWORD') . '@' . env('RABBITMQ_HOST', 'rabbitmq') . ':' . env('RABBITMQ_PORT', 5672) . '/' . env('RABBITMQ_VHOST', '/') . '?heartbeat=' . env('RABBITMQ_HEARTBEAT', 60),
    'queue' => env('REDIS_QUEUE', env('APP_DOMAIN', 'default')),
    'restart_after_seconds' => env('RABBITMQ_RESTART_AFTER_SECONDS', 0),
    'restart_after_jobs' => env('RABBITMQ_RESTART_AFTER_JOBS', 150),
    'restart_after_memory' => env('RABBITMQ_RESTART_AFTER_MEMORY', 0),
],

我们已经尝试调大了Supervisor的stopwaitsecs参数，但问题依然存在。而且这个问题不是100%必现的，有时候Worker重启后批次任务能被其他Worker正常接着处理，有时候就不行，这也给排查增加了不少难度。

我们期望的结果是：Worker自动重启后，批次里的下一个任务能被其他空闲的Worker正常拾取并执行。请问有没有大佬遇到过类似的问题，或者能给一些排查的方向？感谢大家的帮助！

内容来源于stack exchange