Redis键空间通知丢失？检查notify-keyspace-events配置

Redis的键空间通知（Key-space Notifications）默认处于关闭状态，启用它需要显式配置 notify-keyspace-events 参数。许多开发者会遇到“明明配置了，通知却收不到”的困惑——别着急，下面我们逐一排查最常见的几个原因。

notify-keyspace-events 配置值为空或不匹配事件类型

最容易踩的坑是：Redis 实际生效的 notify-keyspace-events 值是空字符串，即完全未开启通知。请注意，即使在 Spring Boot 的 application.yml 中配置了 spring.redis.xxx 相关参数，也无法影响这个键——它仅在 Redis 进程启动时读取，客户端配置无法覆盖。

检查方法很简单：

redis-cli CONFIG GET notify-keyspace-events

• 不要贪心使用 A 或 KEA 这类全量配置——除非你确实需要所有事件，否则 CPU 开销会明显增加。
• Kx 是无效组合：没有 K（keyspace 前缀）时，x 事件仍然会发送，但频道前缀是 __keyevent@0__；添加 K 后反而变成 __keyspace@0__，而 Spring 的 KeyExpirationEventMessageListener 默认只订阅 __keyevent@* 频道。
• 修改后必须重启 Redis 进程（service redis-server restart 或 redis-server --service-stop && redis-server --service-start），因为 CONFIG SET 在部分托管环境（如 Azure Cache for Redis、某些 Docker 镜像）中会被禁用。

Redis 运行在 Cluster 模式下导致通知失效

如果你的 Redis 采用 Cluster 模式，那么键空间通知基本无法正常使用。这并非配置问题，而是协议层的限制：Cluster 将 key 分散到多个节点，keyspace 事件必须由 key 所在的具体节点发布，但客户端订阅的是单个连接，无法跨节点聚合事件。即使对每个节点单独订阅，也会遗漏迁移中或正在重分片的 key 事件。

典型现象是：本地单机 Redis 能收到 __keyevent@0__:expired，一上 Cluster 就完全静默。使用 redis-cli --cluster check 或 CLUSTER NODES 可以确认当前模式。

• Spring Session、Spring Cache 等依赖 keyspace 通知的模块，在 Cluster 下会抛出 IllegalStateException: Unable to configure Redis to keyspace notifications。
• 替代方案只能是业务层轮询 TTL + 定时任务，或者改用 Redis Streams + 生产者主动写入事件。
• 如果必须使用 Cluster 又需要类似能力，则需在应用侧统一管理 key 生命周期（例如使用 Lua 脚本 setex 后立即 PUBLISH 自定义频道）。

监听客户端未正确订阅 __keyevent@N__ 频道

Spring Boot 的 KeyExpirationEventMessageListener 默认只监听 __keyevent@* 模式，但它依赖底层 RedisMessageListenerContainer 的配置。如果容器未启用监听器，或指定了错误的 database，就会收不到事件。

常见问题包括：

• Spring 配置中遗漏了 @Bean 注册 RedisMessageListenerContainer，或容器未调用 setConnectionFactory。
• Redis 连接配置指定了 database=1，但 notify-keyspace-events 只对默认 db0 生效（除非显式设置为 "Exg" 并在代码中订阅 __keyevent@1__）。
• 监听器虽然已注册，但未调用 container.addMessageListener(...)，或者 listener 实现类未添加 @Component 导致 Spring 未扫描到。

验证方法：手动使用 redis-cli 订阅并触发过期：

redis-cli SUBSCRIBE '__keyevent@0__:expired'
redis-cli SET testkey "1" EX 2

另一个常见原因：过期事件本身被延迟或丢弃。Redis 的过期事件并非实时触发，它依赖两种机制协同工作：“惰性删除”（访问时检查）和“定期删除”（后台线程随机抽查）。这意味着：一个 key 到期后，如果无人访问它，且后台抽查未命中，就不会触发 expired 事件——事件仅在 key 真正被删除时发出。后台抽查频率受 hz 参数影响（默认 10），高负载下可能降低，导致事件延迟数秒甚至更久。另外，如果 key 因内存不足被 evict（淘汰）而非自然过期，则发出的是 evicted 事件，而非 expired；此时需要配置 "Exe" 并监听 __keyevent@0__:evicted。

因此，如果你依赖过期事件做定时清理，却观察到“key 消失了但未收到通知”，大概率是它被淘汰了，而不是过期了——查阅 INFO stats 中的 evicted_keys 和 expired_keys 计数即可区分。

关键点在于：键空间通知并不是“事件发生即刻广播”，而是“事件发生且 key 被实际清理时才发出”。许多丢失感知，其实源于对这个时机的误判。