Redis keyspace notification 为什么收不到过期事件

Redis keyspace notification 收不到过期事件，通常不是 TTL 没设置成功，而是“通知没开、事件位不对、频道订错、把 TTL 归零当成删除回调”中的一个。先确认 notify-keyspace-events，再用 __keyevent@*__:expired 做最小订阅；如果是 Redis Cluster，还要连到持有目标 key 的节点。Redis 官方文档地址：https://redis.io/docs/latest/develop/pubsub/keyspace-notifications/

先判断：通知配置、事件位和频道是否匹配

Redis 默认关闭 keyspace notifications，因为它会带来额外 CPU 开销。配置字符串至少要有 K 或 E：前者发布到 __keyspace@__，后者发布到 __keyevent@__；x 才代表 expired 事件。只有写了 x 而没有 K/E，仍然不会收到消息。

用最小配置确认订阅频道和事件类型

先在一个客户端开启最小配置，再在另一个客户端订阅。下面选择 keyevent 形式，因为消息体直接是 key 名称，排查更直观。

# E 选择 keyevent 频道，x 只打开 expired 事件
redis-cli CONFIG SET notify-keyspace-events Ex

# 订阅所有数据库的过期事件；模式中的 * 匹配数据库编号
redis-cli --csv PSUBSCRIBE '__keyevent@*__:expired'

# 在第三个客户端创建一个短 TTL key，观察订阅端的消息体
redis-cli SET demo:ttl "ready" EX 5

如果使用 keyspace 形式，把配置改成 Kx，订阅改为 __keyspace@*__:*；此时频道里包含 key，消息体是事件名 expired。两种形式不要混用。图1把配置位、频道和消息体的对应关系放在同一张静态图里。

expired 事件为什么不是 TTL 归零的实时回调

设置 EXPIRE 时产生的是 expire 相关事件；真正的 expired 事件发生在 Redis 发现 key 已过期并将它从数据集中删除之后。Redis 既可能在访问 key 时惰性删除，也可能由后台过期处理逐步清理，因此 TTL 显示为 0 并不保证通知此刻已经发布。

这也解释了“偶尔收不到”的现象：没有客户端访问的冷 key 可能等待后台清理；订阅端断线期间，Pub/Sub 消息不会补发，事件会直接丢失。图2强调的是删除动作与通知可见性的边界，不是精确时间线。

Cluster 和生产环境还要检查什么

Redis Cluster 中，每个节点只为自己负责的 key 产生通知，通知不会像普通集群 Pub/Sub 那样自动广播到所有节点。要接收完整事件，需要订阅每个节点，或者让应用根据 key 的槽位维护对应连接。

另外，keyspace notification 是实时提示，不是可靠消息存储。它适合清理本地缓存、刷新派生状态等“丢一次也能恢复”的场景；如果业务必须知道每次过期，应该改用 Redis Streams、数据库补偿表或定期扫描做兜底，并给消费者增加幂等处理。

常见追问

为什么配置成 KEA 仍然没有消息？先用 CONFIG GET notify-keyspace-events 确认配置确实写入当前实例，再确认订阅连的是同一实例和正确节点；KEA 也不能弥补断线丢消息。

能否保证 key 到期瞬间收到通知？不能。官方定义是 key 被 Redis 实际删除时生成 expired，不是 TTL 理论值刚好降到零的瞬间。