ThinkPHP队列怎么跑_ThinkPHP队列服务配置说明【解答】

苏承栈

2026-10-07 • 👁 0人浏览过

think-queue不是装完自动运行，必须手动启动消费者进程；php think queue:listen仅前台阻塞监听、适合开发调试，生产环境需用php think queue:work配合Supervisor等进程管理工具保活。

think-queue

不是装完就能自动跑的，它必须手动启动消费者进程来监听和执行任务。默认情况下，所有推入队列的任务都处于“待处理”状态，不会自己运行。为什么

php think queue:listen

启动后没反应？这是最常见误解：以为命令执行完就“生效了”，其实它只是前台阻塞式监听——终端窗口必须保持打开，进程不能被 Ctrl+C 或 shell 退出中断。

php think queue:listen

是开发调试用的，只监听一个队列（默认

default

），不支持多进程、无失败重试兜底一旦终端关闭或 SSH 断连，进程立即终止，任务积压在 Redis/DB 里但没人处理生产环境必须用

php think queue:work

+ 进程管理工具（如 supervisor）保活如果配置了

'default' => 'sync'

，那根本不会进队列，而是直接同步执行——此时

queue:listen

命令压根不生效

queue:work

和

queue:listen

到底该用哪个？看场景选，不是版本高低问题：

queue:listen

：适合本地开发快速验证逻辑，会自动重启 worker（比如改了代码后不用手动 stop/start），但每次只取一个任务，吞吐低

queue:work

：生产首选，支持

--daemon

模式（常驻内存）、

--once

单次执行、

--sleep

空闲休眠、

--max-jobs

限制总执行数，更可控注意：

queue:work --daemon

在 ThinkPHP 6+ 中已被弃用，改用

queue:work

不加参数即可常驻（底层已自动优化）如果你发现

queue:work

启动后立刻退出，大概率是任务类

fire()

方法抛了未捕获异常，导致 worker 进程崩溃 Redis 驱动下任务不消费？先检查这三处 Redis 是最常用驱动，但配置错一处就卡死： PHP 8.5.5 PHP 8.5.5 是 PHP 8.5 分支的维护更新版本。该版本延续了“小步快跑”的迭代逻辑，通过深度错误修复、底层性能微调以及安全加固，旨在为开发者提供一个更健壮、更高效的运行环境。该版本严格遵守语义化版本规范，不包含破坏性变更。下载

config/queue.php

里

'default' => 'redis'

和

'connections.redis.type' => 'redis'

必须一致；若写成

'type' => 'Redis'

（首字母大写）会静默失败

'host'

和

'port'

要跟

config/cache.php

中 Redis 配置完全一致，否则连接的是两个不同实例（尤其 Docker 环境容易 host 写成

localhost

） Redis 的

select

数据库要空闲，比如设为

1

，但实际 Redis 没启用 db1（

redis.conf

中

databases 16

才支持 db1），会导致

BRPOP

阻塞超时却无报错任务类

fire()

执行完不自动删除？这不是 bug，是设计行为：只有成功执行且没抛异常，

think-queue

才从队列中移除该任务。一旦

fire()

抛出异常，任务会被放回队列尾部（可配置重试次数）。立即学习 “ PHP免费学习笔记（深入） ”；务必在

fire()

内部用

try/catch

包住核心逻辑，避免第三方接口超时直接崩掉 worker 调用

$job->delete()

可手动删除（适合“成功但需延迟清理”的场景）；调用

$job->release($delay)

可延后重试 Redis 驱动下，任务原始数据存在

queues:default

list 中，失败任务会进入

queues:default:failed

—— 这个 key 不会自动清理，积多了影响性能真正难的不是跑起来，而是让 worker 在服务器重启、OOM、网络抖动后还能自动恢复消费。supervisor 配置、失败任务归档策略、Redis 内存水位监控，这些才是线上稳定的关键。

相关文章