redis list 比 mysql 表更适合轻量队列，因其 lpush+brpop 原子无锁、单节点扛 5w+ qps；须避免 get/set 轮询，用 brpop 阻塞等待；失败消息应重推并限重试次数；缓存与队列需联动防护；worker 必须由 supervisord 管理生命周期。
高并发下 PHP 队列不是“加了就稳”，而是必须配合消费端健壮性、缓存防护和监控闭环，否则比不加还危险。
为什么 Redis List 比 MySQL 表更适合做轻量队列
MySQL 表存队列在万级并发时会立刻成为瓶颈：INSERT/SELECT FOR UPDATE 争抢行锁，慢查询堆积，连接池打满。而 Redis 的 LPUSH + BRPOP 是原子操作，无锁、无事务开销，单节点轻松扛住 5w+ QPS。
- 别用
GET/SET模拟队列——轮询浪费 CPU，且GET+DEL非原子，高并发下必然丢任务 -
BRPOP必须用，它阻塞等待而非空转，worker 进程 CPU 占用接近 0% - 队列名建议带业务前缀，比如
queue:order:create，避免不同服务混用冲突
消费失败时怎么避免死信堆积
直接 DEL 或忽略失败消息，等于把问题藏进黑洞。真实线上环境，网络抖动、Redis 临时不可达、DB 主从延迟都可能导致一次消费失败。
- 失败后不要删消息，改用
LPUSH把原消息推回队列末尾，并在消息体里加retry_count字段 - worker 启动时读取配置项
max_retry（如 3），超过则lrem删除或转存到failed:queue:order:create供人工干预 - 每次重试前
sleep(rand(1,5))，防止雪崩式重试压垮下游
缓存击穿和队列积压必须联动看
缓存失效瞬间大量请求涌向队列，如果 worker 消费速度跟不上，llen queue:order:create 会一路飙升到几万，而你可能还在查“为什么订单没写进库”。
- 关键缓存 key 必须加互斥锁：
set('lock:goods:list', 1, ['nx', 'ex' => 5])，只有拿到锁的请求才查 DB 并回填 - 过期时间别写死：
$ttl = 3600 + rand(1, 600)，分散失效点 - 监控要拉通：每分钟采样
llen、info memory、缓存命中率，任一指标异常就触发告警或自动降级（如返回兜底商品列表）
最容易被忽略的是 worker 进程的生命周期管理——没人重启的 long-running PHP 进程，不出三天必因内存泄漏卡死。用 supervisord 跑，设置 startsecs=0 和 stopwaitsecs=5，崩溃即拉起，别指望它自己活过一个周末。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
