中小规模PHP业务优先选RabbitMQ；高吞吐强顺序场景才用Kafka。RabbitMQ用php-amqplib+显式heartbeat+delivery_mode=2+delay插件即可；Kafka接入PHP运维成本高、易丢消息、需手动处理offset和flush，且语义差异大。
PHP项目里该用 RabbitMQ 还是 Kafka？看这三点就够了
直接说结论：中小规模 PHP 业务（订单通知、邮件发送、用户行为异步处理）优先选 RabbitMQ；日志采集、实时数仓接入、binlog 同步这类高吞吐+强顺序场景，才值得上 Kafka。别被“高并发”三个字带偏——PHP 本身不是 Kafka 的理想生产者/消费者语言，硬套反而增加运维和可靠性负担。
RabbitMQ 在 PHP 中怎么快速跑起来
用 php-amqplib 是最稳妥的选择，它不依赖系统级扩展，纯 Composer 安装即可：
- 执行
composer require php-amqplib/php-amqplib - 连接时注意
heartbeat参数必须显式设为非零值（比如30），否则长连接容易被中间网络设备静默断开 - 发消息务必设置
delivery_mode = 2，但要清楚这只是“写入磁盘前不丢”，不代表消费者 crash 后能自动重投——得靠ack+requeue逻辑自己兜底 - 延迟任务别自己轮询或 sleep，直接装
rabbitmq-delayed-message-exchange插件，声明 exchange 时指定x-delayed-type: direct就行
Kafka 接入 PHP 的真实代价是什么
表面上 rdkafka 扩展装完就能发，但实际踩坑密度远高于 RabbitMQ：
-
rdkafka是 C 扩展，PHP 版本升级常导致编译失败，7.4 到 8.2 之间至少有三次 ABI 不兼容 - PHP 进程生命周期短，
rdkafka的 producer 缓冲区（queue.buffering.max.messages）若没调小，FPM worker 退出时未 flush 的消息就丢了 - consumer group 的 offset 提交不是自动的，
enable.auto.commit=false是常态，你得自己 handlecommitAsync()失败重试，否则重复消费或跳消息 - Kafka 主题的
retention.ms默认是 7 天，但 PHP consumer 拉取慢时，老消息早被清理了——RabbitMQ 的队列 TTL 是按单条消息算的，更可控
两个中间件混用时，PHP 层最容易漏掉的边界
常见做法是 RabbitMQ 做业务解耦，Kafka 接数据管道，但 PHP 代码里往往忽略协议语义差异：
立即学习“PHP免费学习笔记（深入）”；
- RabbitMQ 的
basic.publish是同步阻塞调用，Kafka 的produce()是异步写缓冲——如果你在 FPM 中发 Kafka 消息后没调poll(0)或等flush()，请求结束即丢失 - RabbitMQ 支持 per-message TTL，Kafka 只能对整个 topic 设
retention.ms，想实现“30 分钟未消费就丢弃”，得在 consumer 侧自己判断时间戳 - 消息体编码：RabbitMQ 默认无强制格式，Kafka 生产者默认用
msgpack或json都行，但 consumer 若用不同语言（比如 Go 写的下游服务），字段类型错位（int vs string）会直接解析失败
真正难的从来不是“怎么连上”，而是“消息从 PHP 发出去之后，到最终被正确消费并产生业务效果”这一整条链路里，每个环节的语义是否对齐、失败是否可感知、重试是否幂等——这些细节藏在配置项和回调逻辑里，而不是文档首页的 hello world 示例中。
