为什么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 22 秒后应看到消息；若没反应，说明不是应用代码问题，而是 Redis 侧配置或模式问题。
过期事件本身被延迟或丢弃
Redis 的过期事件不是实时的。它依赖两种机制协同工作：“惰性删除”（访问时检查）和“定期删除”（后台线程随机抽查）。这意味着：
- 一个 key 到期后，若没人访问它，也无后台抽查命中，就不会触发
expired事件——事件只在 key **真正被删除时**发出 - 后台抽查频率受
hz参数影响（默认 10），高负载下可能降低，导致事件延迟数秒甚至更久 - 若 key 因内存不足被
evict（淘汰）而非自然过期，则发的是evicted事件，不是expired；此时需配置"Exe"并监听__keyevent@0__:evicted
所以，如果你依赖过期事件做定时清理，却观察到“key 消失了但没收到通知”，大概率是它被淘汰了，而不是过期了——查 INFO stats 中的 evicted_keys 和 expired_keys 计数就能区分。
