中小项目应选RabbitMQ而非Kafka实现PHP异步解耦：RabbitMQ用php-amqplib几行代码即可搭建可靠链路，支持vhost隔离、direct交换机路由、Confirm模式与持久化，适配日均万级订单场景；Kafka因PHP生态弱、运维复杂，仅适用于十万级吞吐刚需。
PHP网站需要把订单通知、用户注册邮件、日志上报这些耗时操作从主请求流中剥离出来，避免用户等待接口超时或数据库被压垮，就得靠消息队列做异步解耦和流量削峰。
中小项目直接选RabbitMQ，别碰Kafka
PHP本身不是Kafka的理想语言——FPM进程短命，offset提交、缓冲区flush、retry兜底全得手写，运维成本陡增。而RabbitMQ用php-amqplib几行代码就能跑通可靠链路，语义清晰，中小规模业务（日均订单万级、邮件千封）首选它。
这一步操作起来很简单，直接把文件拖进去就行。
Kafka只在明确需要每秒十万级日志吞吐或binlog实时同步时才值得上；硬套进PHP订单系统，反而让原本5分钟能调通的邮件队列，变成三天还在查offset丢失原因。
立即学习“PHP免费学习笔记（深入）”；
装好RabbitMQ并配好vhost与交换机
先确认RabbitMQ服务已运行：执行sudo systemctl status rabbitmq-server，看到active (running)才算就绪。
访问管控台http://localhost:15672，用默认账号guest/guest登录（生产环境务必改密码）。
点击左侧Virtual Hosts→Add a virtual host，填入/order作为vhost名称，勾选Tracing（便于后续查消息流转）。
切到Exchanges页，选中刚建的/order vhost，在Add a new exchange里填：
– Name：order_exchange
– Type：direct
– Durability：Enabled
– Auto-delete：Disabled
【vhost名必须带前导斜杠，比如/order，不写斜杠会导致php-amqplib连接报404】
用php-amqplib发消息：三步写死可靠性
第一步：安装客户端库：composer require php-amqplib/php-amqplib
第二步：创建生产者脚本producer.php，关键参数不能省：
① 连接必须显式设heartbeat => 30，否则NAT网关静默断连，后续发消息直接Broken pipe；
② 声明交换机时加['durable' => true]，保证RabbitMQ重启后交换机还在；
③ 发消息必须带['delivery_mode' => 2]，这是消息落盘开关——没它，broker崩溃消息全丢；
第三步：调用$channel->confirm_select()开启Confirm模式，再用$channel->wait_for_pending_acks()阻塞等待broker回执，网络抖动时可防TCP缓冲区假成功。
写消费者守护进程：避免FPM退出丢消息
方法一：用supervisor托管长驻进程
写/etc/supervisor/conf.d/order-consumer.conf：
[program:order-consumer]
command=php /var/www/consumer.php
autostart=true
autorestart=true
user=www-data
执行sudo supervisorctl reread && sudo supervisorctl update && sudo supervisorctl start order-consumer启动。
方法二：在consumer.php里手动处理ack逻辑
收到消息后先做业务处理，成功再调$channel->basic_ack($msg->getDeliveryTag())；失败则调$channel->basic_nack($msg->getDeliveryTag(), false, true)重入队列——别漏掉第三个参数true，否则消息会直接被丢弃。
【消费者必须用while(true)循环+sleep(1)保活，不能写成一次性的CLI脚本】
消息路由与削峰实操：按业务类型分发
订单创建后，PHP代码里不再直接发邮件，而是往order_exchange发一条消息，routing_key设为order.created。
在RabbitMQ管控台，进Queues页，创建两个队列：email_queue和log_queue。
分别绑定它们到order_exchange，binding key填order.created和order.payed——这样支付成功的消息只会进log_queue，不会干扰邮件发送流程。
当秒杀活动开始，瞬间涌入2000单，消息全堆在order_queue里；消费者按自身处理能力（比如每秒15条）匀速消费，下游邮件服务和日志系统完全不受冲击。
