不能直接在控制器里发RabbitMQ消息，因为php-fpm同步阻塞模型会导致进程卡在I/O等待，突发流量引发502或超时；正确做法是剥离生产者逻辑，Web层仅做轻量操作并调用封装好的RabbitMQProducer::send()，连接复用且设超时，消费者由supervisor守护并确保手动ack、幂等处理与死信机制。
为什么不能直接在控制器里发RabbitMQ消息？
因为默认的 php-fpm 是同步阻塞模型，一旦在请求中调用 AMQPStreamConnection 建连、发消息，整个 PHP 进程就会卡住等网络 I/O 返回——突发流量来时，大量请求堆积在连接建立或发送阶段，502 Bad Gateway 或超时直接出现。
真正可行的做法是把 RabbitMQ 生产者逻辑从 Web 请求生命周期中剥离出来：
- 用 ThinkPHP 的命令行命令（如
php think queue:work）启动常驻消费者进程，而非每次请求都新建连接 - Web 层只做轻量操作：校验参数、预扣库存（用 Redis）、写日志、调用
Queue::push()把任务推入中间件队列（底层走 Redis 或数据库表） - 确保
queue.php配置里'default' => 'redis'或'database'，而不是'rabbitmq'——ThinkPHP 自带队列驱动不原生支持 RabbitMQ 直连，需额外封装
如何让 RabbitMQ 真正承接住秒杀类突发流量？
RabbitMQ 本身不是“接入口”，它只是缓冲和分发中枢。关键在于三层协同：前端限流 → 中间队列削峰 → 消费端可控吐出。
典型配置要点：
立即学习“PHP免费学习笔记（深入）”；
- 队列必须设为
durable=true，消息delivery_mode=2，避免服务重启丢单 - 消费者端用
prefetch_count控制并发消费数，例如数据库连接池只有 20 个，10 个消费者就设prefetch_count=2，防雪崩 - 不要用一个大队列扛所有订单；按业务拆分，比如
order:create、order:notify、order:log，避免慢任务拖垮快任务 - 生产者发消息前加
try/catch，失败时降级写本地文件队列或重试，别让上游直接 500
ThinkPHP 怎么安全地对接 RabbitMQ？
官方队列不支持 RabbitMQ，但可以绕过框架封装一层适配器，重点解决两个问题：连接复用 + 异常隔离。
推荐做法是独立维护一个 RabbitMQProducer 类，放在 app/common/queue/ 下：
- 使用静态属性保存
AMQPStreamConnection实例，首次调用时初始化，后续复用（注意多进程下不能共享） - 发消息方法内强制设置
timeout=1，超时立即返回 false，不阻塞主流程 - 不依赖 ThinkPHP 的
Queue::push()，而是直接调用封装好的RabbitMQProducer::send('order_queue', $payload) - 在
config/queue.php里保留'default' => 'sync'，仅在需要异步的场景显式调用该类
示例片段（非完整类）：
use PhpAmqpLib\Connection\AMQPStreamConnection;
use PhpAmqpLib\Message\AMQPMessage;
class RabbitMQProducer
{
protected static $connection;
public static function send($queue, $data)
{
try {
if (!self::$connection) {
self::$connection = new AMQPStreamConnection(
config('rabbitmq.host'),
config('rabbitmq.port'),
config('rabbitmq.user'),
config('rabbitmq.pass'),
'/',
false,
'AMQPLAIN',
null,
'en_US',
1 // timeout 秒
);
}
$channel = self::$connection->channel();
$msg = new AMQPMessage(json_encode($data), ['delivery_mode' => 2]);
$channel->basic_publish($msg, '', $queue);
$channel->close();
return true;
} catch (\Exception $e) {
Log::error('RabbitMQ send failed: ' . $e->getMessage());
return false;
}
}
}
消费者进程怎么不死、不漏、不重复？
用 supervisor 管理消费者进程是底线，但光靠它不够。真实线上必须处理三件事：
- 进程崩溃后自动拉起：supervisor 配置
autostart=true和startsecs=0，并加exitcodes=0,2，避免正常退出被误判 - 消息重复投递：消费者处理逻辑必须幂等，比如订单创建前先查 DB 或 Redis 是否已存在该订单号，而不是只靠 RabbitMQ 的
ack - 消息卡住不消费：启用 RabbitMQ 的
dead letter exchange（DLX），设置x-dead-letter-exchange，把三次 nack 的消息转到死信队列人工干预
最容易被忽略的是：消费者代码里没做 $channel->basic_ack($delivery_tag) 手动确认，或者用了 no_ack=true 模式——这意味着只要进程挂了，消息就永久丢失。
