ThinkPHP6支撑1万并发需异步解耦，核心是Redis队列缓冲洪峰、RabbitMQ保障关键任务不丢、Swoole协程高效消费，并辅以防超卖、幂等设计和全链路监控。
ThinkPHP6 要稳定支撑 1 万并发请求，单靠框架默认配置远远不够，关键在于把“同步阻塞”变成“异步解耦”，而队列正是这个链条的核心枢纽。真实线上案例中，1 万并发不是靠堆机器硬扛，而是靠 Redis 队列快速收容、Swoole 协程消费者高效消化、RabbitMQ 保障关键任务不丢，三者按需组合。
Redis 队列：扛住瞬时洪峰的“第一道缓冲池”
秒杀或大促开始瞬间，数万请求涌进下单接口，库存校验、订单生成等操作若同步执行，数据库和 PHP 进程立刻雪崩。此时 Redis 作为轻量级队列后端，承担高吞吐、低延迟的初筛与分流：
- 在 .env 中启用：
QUEUE_CONNECTION=redis，并确保 config/queue.php 的redis配置块 host/port/password 与环境一致 - 队列名建议按业务隔离，如
order_create、email_notify，避免不同任务互相挤压 - 启动多个监听进程分摊压力：
php think queue:listen --queue=order_create --memory=128 --tries=3，配合 Supervisor 管理生命周期 - 控制器中投递任务要轻量，只传必要 ID（如
$orderId），具体数据由 Job 类内部查询，减少序列化开销
RabbitMQ 队列：守护核心链路的“保险丝”
对支付回调、财务对账、物流单同步等不可丢失、需追踪、讲顺序的任务，Redis 的内存特性存在风险。RabbitMQ 提供持久化、ACK 确认、死信队列能力，是订单系统后半程的可靠底座：
- 安装
php-amqplib/php-amqplib后，在 config/queue.php 新增rabbitmq连接配置，vhost 和 login 必须显式指定 - 创建自定义连接器类（如
app/queue/RabbitMQConnector.php），重写connect()方法初始化AMQPStreamConnection - 投递时强制指定驱动：
Queue::connection('rabbitmq')->push(new PayCallbackJob($tradeNo))，避免混用导致语义混乱 - 为关键队列开启
durable=true和delivery_mode=2，确保消息写入磁盘，即使服务重启也不丢失
Swoole 协程消费者：替代 CLI 的“常驻高效引擎”
传统 php think queue:listen 是基于 CLI 的多进程模型，每次启动都加载框架、重建连接，资源消耗大、响应慢。Swoole 协程可让一个进程长期驻留，用 brpop 阻塞监听 Redis 队列，毫秒级响应新任务：
立即学习“PHP免费学习笔记（深入）”；
- 在 config/swoole.php 中启用 Task Worker 模式，分配专用协程处理队列消费
- 编写
app/job/Consumer.php，使用Swoole\Coroutine\Redis连接，调用brpop('default', 0)持续监听 - 每个协程独立执行 Job 的
handle()，失败时记录日志并推入重试队列，不阻塞其他协程 - 配合
go关键字并发拉取多个队列，比如同时监听order_create和user_register
防超卖+幂等+监控：高并发队列不能忽略的三根支柱
队列只是管道，真正决定成败的是任务内容的设计与运维闭环：
- 秒杀场景必须用 Redis 原子命令扣减库存：
decr或eval脚本，返回值 ≤0 则直接拒绝，不在 Job 中查 DB 再判断 - 所有 Job 必须实现幂等：用唯一业务 ID（如订单号）做 Redis 锁或 MySQL 唯一键，防止重复消费
- 接入 Prometheus + Grafana 监控队列积压量、消费延迟、失败率；用 Supervisor 的
autorestart=true自动拉起崩溃进程 - 设置合理的失败重试策略：前 3 次间隔 1s，之后指数退避，超过 5 次转入死信队列人工介入
