Redis 过期事件为什么收不到：notify-keyspace-events 配置与验收方法

线上缓存已经过了 TTL，订阅端却迟迟没有收到通知，通常不是 Redis “没有过期”，而是通知开关、频道方向和事件产生时机没有对上。Redis 的 keyspace notification 默认关闭；要监听过期事件，配置字符串里既要有 keyspace 或 keyevent 方向，也要有 x 这一类事件标志。

先把“过期了”和“收到通知”分成两件事

排查时最容易混在一起的是两个时间点：TTL key 显示的剩余时间，以及 Redis 真正把键删除并发布通知的时间。后台清理线程会逐步扫描过期键；如果键一直没有被访问，过期通知可能比 TTL 归零晚一些。这个延迟本身不能证明订阅失败。

还有不少人踩过的典型坑，是直接把这个通知当成业务事实的唯一来源。keyspace notification 适合做缓存失效提示、开发环境观察和轻量逻辑联动，不适合承载绝对不能丢的订单状态流转、账单结算或延迟任务场景。

notify-keyspace-events 到底要写哪些字符

配置字符串由“通知方向”和“事件类型”组成。K 表示 keyspace 频道，E 表示 keyevent 频道，x 表示 expired 事件。两种方向收到的消息内容不同：

如果消费者要按“所有过期键”统一处理，Ex 通常更顺手；如果只关注某个键的事件，Kx 更直观。两者都开也可以，但会让每次操作产生两种消息，排查时要确认应用没有重复处理。

用一个最小实验确认配置、频道和 TTL 都没错

下面的验证步骤只用数据库 0 和一个短生命周期测试键。先在测试实例上查询配置实际生效值，不要只看部署文件的标注，避免配置没加载成功的乌龙：

CONFIG GET notify-keyspace-events
CONFIG SET notify-keyspace-events Ex
SUBSCRIBE __keyevent@0__:expired

再开一个独立客户端创建测试键，之后分别查看它的剩余 TTL 和键本身是否存在：

SET cache:probe:42 ready EX 5
TTL cache:probe:42
EXISTS cache:probe:42

订阅端收到的消息应该是 cache:probe:42。如果改用 Kx，频道就要换成 __keyspace@0__:cache:probe:42，收到的内容是 expired。订阅的数据库编号、频道前缀和配置方向只要有一处不一致，看起来就像“没有过期通知”。

收到事件后还要做一次业务侧验收

一个可复用的验收不应该只截一行订阅输出。至少记录四个状态：写入时的 TTL、事件频道、消息里的键名，以及消息到达后 EXISTS 的结果。这样能区分“频道错了”“事件还没产生”和“事件到了但业务处理失败”。

• 配置值是否包含 K 或 E，并且包含 x。
• 订阅操作使用的数据库编号，要和写入测试键时用的数据库编号完全一致。
• 收到事件时，对应的键通常已经被删除，不要把读取键值成功当作事件触发的判断条件。
• 应用重连 Redis 之后要重新发起订阅，关键业务场景必须补充额外可查询的状态存储做兜底。

生产环境的三个边界别忽略

Pub/Sub 不是可回放队列

订阅客户端断开的时段里，Redis 已经发布的事件不会缓存下来等重连后补发。需要可靠消费的场景，应该把业务数据写入 Stream、数据库或其他支持回放的持久化存储，把过期通知当作加速处理的信号，而不是唯一的触发源。

集群要按节点观察

Redis Cluster 中，每个节点只发布自己负责的哈希槽范围内键的事件。只连单个节点做订阅，通常只能拿到局部的事件结果；如果业务要求覆盖整个集群，需要逐个订阅所有节点的通知，再在消费侧做事件去重。

配置开关会带来额外开销

通知功能不是零开销，只开启你实际用到的事件方向和类型，不要在生产环境随手开启覆盖范围很大的组合配置。变更配置后要观察对应时段的 CPU 占用、客户端连接数和消息处理延迟，避免意外影响线上业务。

相关问题

为什么 TTL 已经是 0 了还没有 expired？

expired 事件在 Redis 实际删除键时产生，不会严格卡在理论 TTL 到 0 的瞬间触发。后续可以观察键是否被访问、后台清理任务的执行情况，不要一看到事件延迟就直接判定功能故障。

只配置 x 为什么收不到消息？

x 只是事件类型，至少还需要 K 或 E 指定消息发布到哪类频道。

过期通知能不能替代延迟队列？

不建议。它基于 Pub/Sub 实现，断线会丢消息，本身没有消息确认、重试和回放能力。需要实现可靠延迟任务的场景，应该选用自带持久化和消费进度记录的成熟方案。

把排查结论落到一张清单

Redis 过期事件收不到时，按「配置实际值校验 → 订阅频道匹配 → 数据库编号对齐 → 过期触发时机排查 → 可靠性边界确认」的顺序检查，比反复修改订阅业务代码效率高很多。先用最小测试键把事件链路跑通验证，再决定要不要把通知逻辑接入正式业务；涉及核心业务状态的场景，始终要保留一个可查询、支持手动补偿的事实来源。