为什么Redis键空间通知(Key-space Notifications)会丢失_检查notify-keyspace-events配置

Redis默认关闭键空间事件，需显式配置notify-keyspace-events Ex启用过期通知；客户端须订阅__keyevent@N__:expired频道，且仅主节点生成事件。

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

最常见的情况是 Redis 实际生效的 notify-keyspace-events 值为 ""（空字符串），即完全关闭通知。哪怕你在 Spring Boot 的 application.yml 里写了 spring.redis.xxx 相关配置，也不会影响该参数——它只在 Redis 进程启动时读取，且无法通过客户端配置覆盖。

检查方式很简单：

redis-cli CONFIG GET notify-keyspace-events

如果返回 1) "notify-keyspace-events" 2) ""，说明没开；若想监听过期事件，至少得设成 "Ex"（E 表示 keyevent 前缀，x 表示过期事件）。

• 别用 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'<br>redis-cli SET testkey "1" EX 2

2 秒后应看到消息；若没反应，说明不是应用代码问题，而是 Redis 侧配置或模式问题。

过期事件本身被延迟或丢弃

Redis 的过期事件不是实时的。它依赖两种机制协同工作：“惰性删除”（访问时检查）和“定期删除”（后台线程随机抽查）。这意味着：

• 一个 key 到期后，若没人访问它，也无后台抽查命中，就不会触发 expired 事件——事件只在 key **真正被删除时**发出
• 后台抽查频率受 hz 参数影响（默认 10），高负载下可能降低，导致事件延迟数秒甚至更久
• 若 key 因内存不足被 evict（淘汰）而非自然过期，则发的是 evicted 事件，不是 expired；此时需配置 "Exe" 并监听 __keyevent@0__:evicted

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

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