中小规模PHP业务优先选RabbitMQ；高吞吐强顺序场景才用Kafka。RabbitMQ需显式设heartbeat、delivery_mode=2、禁用auto-ack并手动nack+requeue，延迟任务用delay插件；Kafka在PHP中需手动flush、管控offset、调小缓冲区，否则易丢消息。
中小规模 PHP 业务别上 Kafka，RabbitMQ 就够用；真要扛每秒万级日志或 binlog 同步，才值得切 Kafka——但得接受 PHP 层要自己兜底 offset、flush 和消息丢失风险。
RabbitMQ 在 PHP 里怎么避免消息静默丢失
很多人设了 delivery_mode => 2、声明了 durable => true，就以为消息“进了磁盘=稳了”，结果消费者一崩，任务就没了。
- 必须关掉 auto-ack：
$channel->basic_consume($queue, '', false, false, false, false, $callback)，否则消息出队即删 -
heartbeat参数不能省，推荐显式设为30，不然中间网络设备（比如 NAT 网关）可能静默断连 - 消费者 crash 后想重试？得靠
$channel->basic_nack($delivery_info['delivery_tag'], false, true)+ 手动 requeue，不是开个参数就自动回滚 - 延迟任务别手写 sleep 或轮询，装
rabbitmq-delayed-message-exchange插件，声明 exchange 时加x-delayed-type: direct即可
Kafka 的 produce() 在 PHP-FPM 里为什么发着发着就丢消息
因为 rdkafka 的 produce() 是纯异步写缓冲，PHP 请求结束、FPM worker 退出，缓冲区里没 flush 的消息就直接蒸发了。
- 每次
produce()后必须跟$producer->poll(0)或等$producer->flush(1000)成功，否则不保险 -
queue.buffering.max.messages默认是 100000，FPM 场景下建议调小到 100–1000，减少未 flush 消息量 - consumer 不设
enable.auto.commit=false，或者 commit 失败不重试，就会跳消息或重复消费 - PHP 进程短命，
retention.ms设再大也没用——如果 consumer 拉得太慢，Kafka 已经把老消息清掉了
Redis List 队列在什么情况下能用、什么情况下千万别碰
它快、轻、零依赖，但只适合“丢了也不心疼”的场景。一旦你开始写 BRPOP task_queue 0，就已经踩进坑了。
- 超时必须设非零值，比如
BRPOP task_queue 10，配合脚本重试逻辑，否则进程卡死或被 kill 后消息永久消失 - 没有 ACK，
BRPOP返回即从链表删，消费者处理中途崩溃 = 消息彻底丢失 - 多个 worker 同时
BRPOP同一个 key，看似负载均衡，实则只是 Redis 单线程轮流返回，根本不是并发消费 - 想实现延时重试？得自己用
ZSET存时间戳 + 定时脚本轮询，不是原生能力，维护成本远超收益
MySQL 做队列为什么必须加 FOR UPDATE SKIP LOCKED
不加这个，高并发下两个 worker 同时查到同一条 status = 0 的记录，都 update 成 1，任务就被执行两次——这在订单、支付类业务里是致命问题。
-
SELECT ... FOR UPDATE默认会阻塞第二个查询，造成 worker 等锁、响应变慢；SKIP LOCKED让它直接跳过已锁行，查下一条，这才是真正并发出队 - 必须包裹在事务里：
BEGIN→SELECT ... FOR UPDATE SKIP LOCKED→UPDATE ... SET status = 1→COMMIT - MySQL 5.7 及更早版本对
SKIP LOCKED支持不完整，线上用前务必验证执行计划是否真的跳过锁行
最常被忽略的点：RabbitMQ 和 Kafka 在 PHP 里根本不是同一类抽象。RabbitMQ 的 basic_publish 是同步调用，发完就返回；Kafka 的 produce 是异步写缓冲——混用时，光看函数名容易误判语义，结果在 FPM 里发完不 poll，消息就没了。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
