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如果返回
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'2 秒后应收到消息；若无反应，说明不是应用代码问题，而是 Redis 侧配置或模式问题。
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 被实际清理时才发出”。许多丢失感知，其实源于对这个时机的误判。
