yii2使用redis实现延时队列消息丢失是系统性问题，主因包括：redis keyspace notifications未启用（需配置notify-keyspace-events为"ex"）、yii2-queue监听进程未常驻运行、连接超时无重试机制及内存淘汰策略误驱逐未过期消息。
Yii2 使用 Redis 驱动实现队列延时任务时，消息丢失不是偶发异常，而是典型配置或机制误用导致的系统性问题。核心原因集中在 Redis 本身对“延时”的支持方式、Yii2-queue 的实现限制，以及生产环境常见疏漏三方面。
Redis Keyspace Notifications 未启用或配置错误
Yii2 原生 yii\queue\redis\Queue 不直接支持毫秒/秒级延时投递（如 delay(30)），它依赖 Redis 的过期事件（keyspace notification）触发回调。但该功能默认关闭：
-
配置项缺失：redis.conf 中
notify-keyspace-events必须显式设为"Ex"（E=事件，x=过期），仅写"e"或留空均无效 -
数据库不匹配：监听脚本订阅的是
__keyevent@0__，但实际 key 写入了 db 1，事件永远收不到 -
服务未重启：改完配置后只 reload 不行，必须
service redis-server restart才生效
Yii2-queue 的延时机制存在固有盲区
即使 Redis 事件正常，Yii2-queue 的 delay() 仍可能丢消息：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
监听进程未运行：Keyspace 事件需常驻 PHP 进程订阅（如
php yii queue/listen --verbose），该进程必须由 Supervisor 管理；手动运行后关闭终端，监听即终止 -
事件竞争与重复消费：一个 key 过期可能触发多次
del事件，而 Yii2-queue 默认不幂等处理，导致消息被重复入队或跳过 -
超时清理干扰：若同时启用了
yii\queue\redis\ClearExpiredJob类，它会主动DEL过期 key，反而抢在事件通知前清掉消息
Redis 连接与数据可靠性隐患
底层连接不稳定会直接导致延时消息写入失败或读取中断：
-
连接超时未重试：Yii2-queue 默认不重试 Redis 操作，网络抖动时
LPUSH延时队列失败，错误静默吞掉，日志里只显示“failed to push job” -
密码或 database 错配：缓存组件和队列组件共用 redis 配置，但队列配置漏了
password，连接降级到无认证端口，写入被拒绝却无报错 -
内存淘汰策略影响：Redis 设置了
maxmemory-policy allkeys-lru，当内存满时，未过期的延时消息 key 可能被提前驱逐
验证与快速定位步骤
按顺序执行以下检查，90% 的丢失问题可定位：
- 登录 Redis：
redis-cli -h 127.0.0.1 -p 6379 -a yourpass，执行CONFIG GET notify-keyspace-events，确认返回1) "notify-keyspace-events" 2) "Ex" - 手动模拟延时流程：
SET test_delay "hello" EX 5，另起终端执行redis-cli PSUBSCRIBE '__keyevent@*__:expired'，看是否收到test_delay事件 - 查 Supervisor 状态：
supervisorctl status，确认yii-queue-listen处于RUNNING，且pid不为 0 - 翻
/var/log/supervisor/yii-queue-listen-*.log，搜索exception、failed、connection refused
