laravel并发靠多个独立queue:work进程并行消费队列，而非多线程；每个进程抢占任务执行，redis用brpop、database用行锁保证不重复，需配合supervisor管理、合理配置retry_after与block_for防失败和延迟。
并发任务在 Laravel 里不是靠“开多个线程”实现的，而是靠多个 queue:work 进程并行消费同一个队列（或不同队列），配合合适的驱动和参数控制吞吐与隔离。直接起多个 php artisan queue:work 就是并发，但乱配会丢任务、卡死、超时或互相干扰。
为什么 queue:work 启多个就等于并发？
Laravel 的 queue:work 是单进程、阻塞式消费者：它拿到一个任务 → 执行 handle() → 标记完成 → 再取下一个。所以一个进程只能串行处理。要并发，就必须启动多个独立进程，各自从队列里抢任务。Redis 驱动天然支持原子出队（BRPOP），database 驱动靠数据库行锁模拟，都能避免重复消费。
关键点：
- 每个
queue:work进程是完全独立的 PHP 实例，内存不共享，失败互不影响 - 并发数 = 启动的 worker 进程数，不是靠代码里写
for循环或Promise - database 驱动下高并发可能触发表锁争用，Redis 更稳
- 别用
queue:listen—— 它已废弃，无内存回收，跑久必崩
如何安全启动多个 worker 并发消费？
手动调试时可以开多个终端分别运行：
php artisan queue:work --queue=default --sleep=1 --max-jobs=50 php artisan queue:work --queue=default --sleep=1 --max-jobs=50 php artisan queue:work --queue=default --sleep=1 --max-jobs=50
但生产环境必须用 Supervisor 管理，否则终端关闭、OOM 或异常退出后进程就没了。Supervisor 配置核心项：
-
numprocs=4：启动 4 个相同配置的 worker -
process_name=%(program_name)s_%(process_num)02d：避免日志/进程名冲突 -
command=php /var/www/artisan queue:work --queue=default --sleep=3 --tries=3 --max-time=3600：加--max-time防止长任务霸占进程 -
autorestart=true和startsecs=5：崩溃后自动拉起
注意：--queue=default 必须和 QUEUE_CONNECTION 匹配；若设 QUEUE_CONNECTION=redis，命令里就不能写 queue:work database。
并发下任务失败、重试、超时怎么不出乱子？
多个 worker 同时跑，失败策略不统一会导致任务被反复重试、堆满 failed_jobs 表，甚至因事务连接复用引发数据错乱。
必须在任务类里显式声明：
-
public $tries = 3;：总重试次数（不是每 worker 各试 3 次） -
public $retryAfter = 60;：失败后多少秒再入队（Redis 下生效） -
public $maxExceptions = ['App\Exceptions\NetworkTimeoutException'];：特定异常不重试，直接进 failed_jobs
特别注意：
-
retry_after必须大于任务最坏执行时间，否则未完成就被系统标记为失败——比如你设了retry_after=30，但 handle() 里有个 API 调用偶尔要 45 秒，那这任务必丢 - database 驱动下，
failed_jobs.exception字段只存前 65535 字节，超长堆栈会被截断；查完整错误得翻storage/logs/laravel.log - 别在
handle()外层包DB::transaction()，长生命周期 worker 可能复用连接，导致事务状态污染
Redis 驱动并发卡住不动？先看 block_for 和 prefix
现象：Supervisor 显示 4 个 worker 正在运行，但新任务进队后几秒甚至几十秒才开始处理，或干脆不动。
大概率是 block_for 参数没关，或者 Redis key 冲突：
- 在
config/queue.php的redis配置块里加'block_for' => null：让 BRPOP 不设超时，有任务立刻响应；默认 5 秒轮询会造成延迟 - 确认
'prefix' => 'queues:'已设置，否则多个 Laravel 项目共用 Redis 时，queues:default会被互相覆盖 - 检查
retry_after是否远小于实际耗时，导致任务刚入队就被判定“超时失败”，反复进出队列
并发本身不难，难的是每个 worker 进程的状态隔离、失败边界控制、以及 Redis 连接行为对轮询逻辑的实际影响——这些细节漏掉一个，就可能让“并发”变成“假并发”或“事故并发”。
