PHP用Redis实现队列的最简路径是lpush入队、rpop出队，利用List模拟FIFO；生产环境须用brpop设超时，失败任务应进独立重试队列并带retry_count字段，避免死循环；rpop/brpop原子性保障并发安全，但需配合processing哈希表实现确认机制。
PHP 用 Redis 实现队列，lpush 和 rpop 是最简可行路径
别绕弯子：PHP 操作 Redis 队列，核心就是 lpush 入队、rpop 出队。Redis 本身没“队列类型”，靠 List 结构 + 这两个命令模拟 FIFO 行为。rpop 是阻塞安全的——它天然支持空时返回 null，不报错，适合轮询；但若想避免忙等，得配合 brpop。
常见错误是误用 lpop + rpush，看似对称，实则顺序反了，变成 LIFO（栈）；还有人用 lrange 扫描整个队列，一来性能差，二来并发下可能漏任务。
-
lpush从左边推入，rpop从右边弹出 → 真正 FIFO - 生产环境务必用
brpop替代rpop，带超时（如brpop('queue', 30)），避免 worker 空转耗 CPU - 不要在循环里无休止
rpop，没任务时立刻 sleep 或交还控制权
任务失败后怎么重试？别直接 lpush 回原队列
直接把失败任务塞回原队列头部（lpush），会导致它被立刻重取，形成死循环。更糟的是，如果失败原因是临时性问题（如下游接口超时），高频重试会雪崩。
正确做法是引入延迟队列机制：失败任务写入一个带过期时间的 key，比如用 zadd + 时间戳做 score，再由单独的扫描进程按时间捞取；或者更轻量——用另一个队列存重试任务，并加计数字段（如 retry_count），每次重试前检查是否超限。
立即学习“PHP免费学习笔记（深入）”；
- 原队列只负责“首次分发”，失败任务进
retry_queue，不是main_queue - 重试任务的 payload 里必须带
retry_count字段，PHP 反序列化后先判断是否 ≥3 再决定丢进死信队列 - 别用
expire给 list key 设过期——Redis 的 list 不支持过期，只能对 key 整体设，但 pop 后 key 还在，过期逻辑就乱了
多个 worker 并发消费时，rpop 不会重复取同一个任务
Redis 的 rpop 和 brpop 是原子操作，这点很关键。即使 10 个 PHP 进程同时执行 $redis->rpop('queue')，Redis 内部会确保只有一个拿到元素，其余返回 null。不用加锁，也不用 Lua 脚本兜底。
但要注意：拿到任务后，业务处理过程中崩溃或超时，这个任务就丢了。所以必须搭配「确认机制」——典型做法是任务 pop 出来后，先 hset 到一个 processing hash 表，处理完再 hdel；定时任务扫描这个 hash 表，把超时未完成的 key 拉回来重投。
- 不要依赖 PHP 进程生命周期做状态管理，worker 可能被 kill -9
- processing 状态建议用
hset而非单独 key，方便用hgetall批量扫 -
brpop的 timeout 值别设太小（如 1 秒），否则网络抖动会导致大量假空轮询
用 phpredis 扩展还是 Predis？优先选 phpredis
phpredis 是 C 扩展，性能高、内存稳，和 Redis 协议贴合紧；Predis 是纯 PHP 实现，调试友好但吞吐低，尤其在高并发 pop 场景下容易成为瓶颈。线上跑队列，没理由不用 phpredis。
安装时注意 PHP 版本兼容：PHP 8.0+ 要用 phpredis 5.3.4+，旧版本装上可能 brpop 返回格式异常（比如多包一层 array）。另外，连接必须复用——每个请求 new Redis() 是大忌，要用连接池或静态实例。
- 确认扩展已启用：
extension=redis.so在 php.ini 里，且php -m | grep redis有输出 - 连接实例建议封装成单例，避免频繁 connect/disconnect 开销
- 别在
__destruct里 close 连接——PHP 请求结束时自动释放，手动关可能触发 warning
brpop 的 timeout 和 processing 状态的清理节奏，调不好，系统就卡在半空里。 
