不支持。Redis PUB/SUB是纯内存广播机制，消息不存储、无TTL、不落盘，无法设置过期时间；实现定时任务需依赖SET+EXPIRE配合__keyevent@0__:expired事件监听。
不能直接用 Redis Pub/Sub 实现“定时”任务，它只负责广播信号，不提供时间控制能力；真正的“定时”必须由 SET + EXPIRE + __keyevent@*__:expired 组合承担，Pub/Sub 只能用来动态通知“现在该检查了”。
为什么 PUBLISH 不能替代 EXPIRE 做定时
Pub/Sub 是即发即弃的广播通道，没有延迟、没有调度、不存历史消息。你执行 PUBLISH task:trigger "now"，只是喊了一嗓子，没人保证谁听见、什么时候听见、听见几次。
- 订阅者断连 2 秒，这期间所有
PUBLISH全部丢失 - 你无法让 Redis 在 5 秒后自动发一条消息——它根本不支持“延时发布”
- 想模拟定时？只能靠客户端自己 sleep 或轮询，那就退化成单机 cron，失去分布式意义
真正可用的动态触发组合：EXPIRE 定时 + PUBLISH 唤醒
把 Pub/Sub 当作“敲门声”，把 key 过期当作“闹钟”。关键不是让它发任务，而是让它提醒大家：“快去查有没有新过期的任务！”
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 业务侧调用
SET task:123 "run" EX 600设置一个 10 分钟后过期的任务键 - 同时
PUBLISH task:refresh "123"，通知所有节点“有个新任务来了，快更新本地缓存或检查队列” - 监听
task:refresh的服务收到后，可立即触发一次 ZSET 轮询（比如查zrangebyscore task:schedule -inf +inf），避免等待下一轮固定扫描周期 - 真正的执行仍由
__keyevent@0__:expired监听器捕获task:123过期事件来完成，这才是唯一可靠的时间锚点
CONFIG SET notify-keyspace-events Ex 必须验证是否生效
配置写进 redis.conf 不等于生效，Docker 镜像、云 Redis（如阿里云 Tair、腾讯云 CRS）默认关闭键空间通知，且部分托管服务禁止运行时修改。
- 先确认数据库编号：你
SET到的是 db 0 还是 db 2？订阅必须匹配，比如 db 2 就得PSUBSCRIBE __keyevent@2__:expired - 别只信
CONFIG GET notify-keyspace-events返回Ex，要实测：开两个redis-cli，一个PSUBSCRIBE __keyevent@0__:expired，另一个SET test:x "1" EX 3，3 秒后没收到pmessage就说明没通 - Spring Boot 中若用
KeyExpirationEventMessageListener，它默认监听所有 DB，容易被 session、cache 等无关过期 key 打爆线程，务必手动注册PatternTopic("__keyevent@0__:expired")并在回调里用new String(message.getBody())提取 key 名做前缀过滤
动态触发最易被忽略的三个点
多数人卡在“能发能收”，却在线上突然失效——问题往往不出在代码，而在基础设施层。
- Redis 主从切换时，
__keyevent@*__:expired只在主节点触发，从节点不发事件；如果你的监听器连的是从节点（比如用了读写分离连接池），永远收不到过期通知 -
PUBLISH后没有做幂等校验，网络重传或多个服务同时PUBLISH task:refresh "123"，会导致下游重复刷新、重复拉取、重复入队 - 任务键名设计没考虑分片，比如全用
task:123，集群模式下可能落在不同 slot，而KEYEVENTS是单节点事件，跨节点过期不会广播到其他 master
