redis pub/sub 不支持延迟投递，一发即广播、离线即丢失；可靠延时需绕开pub/sub，改用zset存消息+调度器触发publish，并用lua保证原子性。
Redis Pub/Sub 本身不支持延迟投递，强行塞时间戳进去也没用——它根本不会等，一发就广播，离线就丢。
Pub/Sub 的实时性是硬限制，不是配置能改的
调用 PUBLISH 的瞬间，Redis 就把消息推给所有当前在线的 SUBSCRIBE 客户端。它不看消息内容里有没有“10秒后执行”，也不存、不延、不重试。如果消费者此时断连，这条消息永远不会再出现。
常见错误现象：
- 写了个带时间字段的 JSON 消息，比如
{"at":1717023600000,"data":"xxx"}，以为订阅端解析后 sleep 等待，结果服务一重启或网络抖动，sleep 就中断，消息状态丢失 - 用客户端定时器模拟延时，但没做幂等和失败恢复，导致重复发或漏发
- 误以为
PSUBSCRIBE能兜底——其实通配符订阅一样只收实时流，不缓存历史
ZSET 是目前最可控的轻量级替代方案
核心不是“让 Pub/Sub 变慢”，而是“绕开 Pub/Sub，用 ZSET 存+调度器触发真正的 PUBLISH”。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
关键操作链：ZADD delay:queue 1717023600000 "msg:order_123" → 调度器轮询 ZRANGEBYSCORE delay:queue -inf (1717023600000 → 对每个 member 执行 PUBLISH notify:channel "msg:order_123" → ZREM delay:queue "msg:order_123"
必须注意的点：
- score 用毫秒时间戳（不是秒），避免精度不足导致批量误触发
-
ZRANGEBYSCORE的开区间写法(1717023600000防止同一时间戳多条消息被重复取到 - 取出和删除不能分两步走——得用 Lua 脚本包裹
ZRANGEBYSCORE+ZREMRANGEBYSCORE，否则中间崩溃会导致消息卡住 - 单机调度器挂了，ZSET 里的消息就停在那儿；生产环境至少得加个健康检查+自动拉起，或者用 Redisson 的
RDelayedQueue封装好的逻辑
别踩键过期通知（Keyspace Notifications）这个坑
有人想用 EXPIRE + __keyevent@0__:expired 订阅来“触发延时”，理论上实时性好，但实际线上几乎不可靠：
- Redis 不保证过期事件 100% 投递，主从切换、AOF rewrite、内存淘汰都可能丢事件
- 事件只发 key 名，你得自己维护
key → message映射，又引入新存储和一致性问题 - 大量短延时 key 会集中过期，造成事件风暴，消费端来不及处理就积压
- 必须显式开启
notify-keyspace-events Ex，很多云 Redis 默认关闭，且部分托管服务不开放该配置
真正难的不是把消息塞进 ZSET，而是调度器怎么扛住高并发到期、怎么防止单点故障、怎么让失败消息可追溯——这些细节一旦漏掉，延时队列就从“省事方案”变成“事故温床”。
