TP8.0队列积压需双管齐下：先确认Redis驱动生效及消费者状态，再通过Supervisor扩容至6个worker进程并行消费；同时优化任务逻辑——剥离同步调用、批量SQL更新、非关键场景关闭自动提交。
TP8.0项目中订单、通知类队列任务持续积压，消费者进程数不足叠加单条任务处理耗时过高，导致Redis队列长度突破50万条，HTTP接口响应延迟超8秒，部分定时任务已错过执行窗口。
确认当前消费者运行状态与队列积压量
执行php think queue:status命令，查看当前活跃消费者数量及各队列待处理任务数；若返回No workers running或消费者数为1，说明根本未启动多进程消费机制。
运行redis-cli -a your_password llen 'queue:default'（将your_password替换为实际Redis密码），直接读取Redis中队列长度；当结果大于10000时，必须立即干预，否则内存占用会持续飙升直至OOM。
【关键前提】确保config/queue.php中'default' => 'redis'已生效，且'redis' => [...]配置项指向正确的Redis实例——若仍为'sync'驱动，所有所谓“增加消费者”操作均无效，任务只是在内存里同步执行完就消失。
快速扩容消费者进程数（水平扩展）
方法一：使用supervisor守护多进程（推荐生产环境）
第一步：创建supervisor配置文件/etc/supervisor/conf.d/thinkphp-queue.conf，内容如下：
[program:tp8-queue-worker]
command=php /var/www/tp8/think queue:work --queue=default --delay=3 --sleep=3 --max-jobs=0 --memory=128 --tries=3
autostart=true
autorestart=true
user=www-data
numprocs=6
process_name=%(program_name)s_%(process_num)02d
redirect_stderr=true
stdout_logfile=/var/log/tp8/queue_worker.log
第二步：重载supervisor配置并启动全部进程：supervisorctl reread → supervisorctl update → supervisorctl start tp8-queue-worker:*
这一步会立刻拉起6个独立的worker进程，并行消费default队列；注意numprocs=6不可盲目设为CPU核心数的2倍，TP8.0的queue:work默认不支持协程，每个进程独占一个PHP-FPM子进程，设太高反而引发内存竞争。
优化单条任务处理逻辑（垂直提效）
方法一：剥离同步阻塞调用
检查任务类中fire()方法，将库存扣减、短信发送、邮件推送等外部HTTP/API调用全部改为异步：用think\facade\Queue::push()投递子任务，主任务只做数据校验和状态标记；例如原逻辑SmsService::send($phone, $msg)必须替换成Queue::push(SendSmsJob::class, ['phone'=>$phone, 'msg'=>$msg])。
方法二：批量数据库操作替代逐条更新
若任务需更新1000条订单状态，禁止循环执行Order::where('id', $id)->update(['status'=>2])；改用Order::whereIn('id', $orderIds)->update(['status'=>2])，一次SQL完成全部更新，可将耗时从3.2秒降至0.15秒。
方法三：关闭事务自动提交（仅限非强一致性场景）
在任务类fire()开头添加Db::setAutoCommit(false)，结尾手动Db::commit()；该操作跳过InnoDB每条SQL的redo log刷盘，适合日志归档、报表生成等允许短暂最终一致性的任务。但【切勿用于订单支付、资金结算类任务】，否则可能丢失数据。
