Redis List 队列仅适合任务可丢、无需严格顺序与死信处理的内部小流量场景，因其无ACK机制、不支持优先级/延时/死信，BRPOP超时设为0易致消息丢失。
Redis List 队列适合什么场景？为什么别乱用 BRPOP
Redis 的 LPUSH + BRPOP 是 PHP 里最轻量、上手最快的队列方案，但只适合「任务可丢、不需严格顺序保障、无死信处理需求」的内部小流量异步任务，比如日志归档、邮件触发、缓存预热。
- 常见错误现象：
BRPOP超时设为 0（无限等待），消费者进程卡死或被信号中断后消息丢失；多个消费者同时BRPOP同一个 key，看似负载均衡，实则因 Redis 单线程特性无法真正并发出队，只是轮流抢 - 必须设置合理超时，例如
BRPOP task_queue 10，配合脚本重试逻辑，避免单点阻塞拖垮整个 Worker - 不支持消息确认（ACK），一旦
BRPOP返回就从链表删掉，消费者崩溃=消息永久丢失；若业务要求“至少一次”，就得自己加 Redis Hash 存消费状态，复杂度陡增 - 没有优先级、延时、死信机制，想实现“5 分钟后重试”，只能靠
ZSET+ 定时轮询，不是原生能力
RabbitMQ 的 delivery_mode=2 不等于消息不丢
很多 PHP 开发者以为只要在 AMQPMessage 构造时设 delivery_mode => 2，再把队列声明为 durable => true，消息就绝对可靠——这是典型误解。RabbitMQ 的持久化只保证“写入磁盘前不丢”，不保证“消费者宕机后能重投”。
- 常见错误现象：消费者处理失败后没调用
$channel->basic_nack()，也没开启no_ack => false，导致消息被自动删除，无法重试 - 必须显式关闭 auto-ack：
$channel->basic_consume($queue, '', false, false, false, false, $callback)，否则哪怕 delivery_mode=2，消息一出队就丢 - 镜像队列（Mirrored Queues）在 3.8+ 已废弃，改用 Quorum Queue；若还在用老集群，节点宕机可能丢未同步的持久化消息
- PHP 连接断开时未捕获
AMQPConnectionException，导致生产者静默失败，前端以为任务已提交成功
MySQL 队列表为什么加 FOR UPDATE SKIP LOCKED？
用 MySQL 做队列，核心不是“能存”，而是“并发安全”。不加 FOR UPDATE SKIP LOCKED，高并发下会出现任务重复消费或死锁，尤其在 MySQL 5.7 及更早版本中几乎必现。
- 常见错误现象：两个 Worker 同时 SELECT 到同一条 status=0 的记录，都 UPDATE 成 status=1，结果同一任务被执行两次
-
SELECT ... FOR UPDATE会锁住整行，但默认行为是“等待锁释放”，造成第二个查询阻塞；SKIP LOCKED让它跳过已被锁的行，直接查下一条，这才是真正的并发出队 - 必须搭配事务：SELECT 和后续 UPDATE 必须在同一事务内完成，否则锁释放后到 UPDATE 之间存在时间窗，仍可能被其他 Worker 插入
- status 字段务必建索引，且 WHERE 条件要能命中索引（如
WHERE status = 0 ORDER BY id LIMIT 1），否则全表扫描 + 锁表，性能雪崩
Kafka-PHP 消费者为什么总卡在 offset 提交失败？
rdkafka 扩展里 KafkaConsumer::commit() 失败不是偶发网络问题，大概率是消费者组（group.id）配置或 Topic 分区分配策略没对齐，尤其是 PHP Worker 重启频繁时极易触发。
立即学习“PHP免费学习笔记（深入）”；
- 常见错误现象：日志反复报
Local: No offset stored或Commit failed: Local: No offset stored，消费者停摆，新消息堆积 - 必须确保
enable.auto.commit => false，手动控制 commit 时机；否则自动提交可能在业务逻辑执行前就完成，导致 crash 后重复消费 - PHP 进程生命周期短（如 CLI 脚本每次跑完就 exit），不能依赖 librdkafka 内部的后台提交线程；每次退出前必须显式调用
$consumer->commit()，并检查返回值 - group.id 相同但
session.timeout.ms设得太小（如 6s），Worker 处理慢一点就被踢出组，rebalance 后 offset 重置，历史消息重放
