本文详解如何通过启动多个队列工作进程（queue:work），让 laravel 同时并行执行多个队列任务，显著缩短批量耗时作业（如验证码获取）的整体处理时间。
本文详解如何通过启动多个队列工作进程（queue:work），让 laravel 同时并行执行多个队列任务，显著缩短批量耗时作业（如验证码获取）的整体处理时间。
在 Laravel 应用中，当需要高频调度耗时任务（例如每个 GetCaptcha 任务需 10 秒），若默认单工作进程串行执行，100 个任务将耗时约 1000 秒——用户体验与系统吞吐量均严重受限。关键优化路径并非修改任务逻辑，而是提升队列消费能力：通过并发运行多个队列工作者（workers），实现真正的并行处理。
✅ 正确做法：启动多个 queue:work 进程
Laravel 原生支持多 worker 并发消费同一队列。只需在终端中并行启动多个 php artisan queue:work 实例即可：
# 终端 Tab 1 php artisan queue:work --queue=default --sleep=3 --max-jobs=100 # 终端 Tab 2 php artisan queue:work --queue=default --sleep=3 --max-jobs=100 # 终端 Tab 3 php artisan queue:work --queue=default --sleep=3 --max-jobs=100
? 每个进程独立监听 default 队列，Laravel 的队列驱动（如 database、redis、database）会自动通过原子锁或事务保证同一任务仅被一个 worker 获取，避免重复执行。
? 生产环境：使用 Supervisor 管理多 Worker
本地测试可用多终端，但生产环境必须借助进程管理器（如 Supervisor）确保稳定性与自愈能力。以下为典型的 supervisord.conf 片段配置（以 4 个并发 worker 为例）：
[program:laravel-worker] process_name=%(program_name)s_%(process_num)02d command=php /var/www/your-app/artisan queue:work --queue=default --sleep=3 --max-jobs=500 --timeout=90 autostart=true autorestart=true user=www-data numprocs=4 redirect_stderr=true stdout_logfile=/var/log/your-app-worker.log stopwaitsecs=30
⚠️ 注意事项：
- numprocs=4 表示启动 4 个独立 worker 进程，即理论最大并发数为 4；
- --timeout=90 需大于单任务最坏耗时（如 GetCaptcha 若超时应设 ≥15s），防止被误杀；
- --max-jobs=500 可防止内存泄漏，建议定期重启 worker；
- 使用 --tries=3 可增强失败任务的容错性（配合 failed_jobs 表）；
- Redis 驱动性能优于 database，高并发场景推荐切换。
? 调度端无需修改：保持简洁可靠
你的任务分发代码完全无需改动，仍保持清晰语义：
// 批量分发 —— 依然是毫秒级完成
foreach ($taskIds as $taskId) {
GetCaptcha::dispatch($taskId)
->afterCommit()
->onQueue('default');
}Laravel 的 dispatch() 仅向队列表（或 Redis）写入任务元数据，真正耗时的执行由后台 worker 异步承担。并发 worker 数量直接决定整体吞吐上限。
✅ 总结
- ✅ 核心原理：多 worker = 多消费者 = 真正并行（非协程伪并发）；
- ✅ 零代码侵入：不改任务类、不改分发逻辑、不引入第三方包；
- ✅ 生产就绪：Supervisor / PM2 / Systemd 均可标准化部署；
- ⚠️ 务必监控：配合 horizon 或日志分析，观察队列延迟、失败率与 worker 负载；
- ? 横向扩展提示：单机资源见顶后，可将 workers 分布至多台机器，共用同一 Redis/DB 队列服务。
通过合理配置并发 worker 数量（建议从 2–4 起步，结合 CPU 核心数与任务 I/O 特性调优），你可在不重构业务逻辑的前提下，将原本线性增长的处理时间压缩为近似常数级，大幅提升 API 响应效率与系统可伸缩性。
