Redis过期事件监听需手动配置notify-keyspace-events为Ex、订阅过期频道并编写监听器，集群需全节点订阅，且存在丢失、延迟与重复风险，须通过幂等设计和二次落库保障可靠性。

Redis 数据过期事件监听不是“自动触发业务逻辑”的魔法开关，而是一套需要手动配置、精准订阅、可靠消费的机制。它本身不执行关单、回库、发通知等动作，只负责在 Key 被 Redis 清理前，广播一条“这个 Key 过期了”的消息。真正干活的，是你写的监听器和背后的业务代码。

必须开启的底层开关：notify-keyspace-events

Redis 默认完全关闭键空间事件通知，过期监听根本不会发生。关键一步是修改所有 Redis 实例（单机或集群每个节点）的配置：

• 编辑 redis.conf，找到 notify-keyspace-events 行，将其设为 Ex
• E 表示启用键事件通知，x 表示仅关注过期（expired）事件，这是最常用也最轻量的组合
• 配置生效需重启 Redis；生产环境严禁依赖 CONFIG SET 临时设置，否则重启即失效

Spring Boot 中的标准监听写法

Spring Data Redis 提供了开箱即用的支持，核心是两部分：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 声明一个 RedisMessageListenerContainer Bean，它是消息监听的容器，负责连接、订阅、分发
• 定义一个监听器类，继承 KeyExpirationEventMessageListener（推荐），或实现 MessageListener 接口
• 监听器中重写的 onMessage 方法会收到过期 Key 的名称，此时可调用订单服务、库存服务等完成后续动作

集群环境下的特殊注意事项

Redis 集群中，每个分片（shard）独立管理自己的数据和过期事件。这意味着：

• 监听器必须能连接到整个集群，而不是单个节点
• 不能只订阅某一个节点的 __keyevent@0__:expired 频道，而要确保客户端能接收来自所有主节点的该频道消息
• 使用 Redisson 可大幅简化这一过程，它内置集群拓扑发现与多节点事件聚合能力，比原生 Spring Data Redis 更适合生产集群

实际业务中容易踩的坑

监听本身只是起点，落地时常见问题集中在可靠性和时效性上：

• 事件可能丢失：Pub/Sub 是“发后即忘”模型，若监听服务宕机或未及时消费，过期消息就没了。关键业务建议将监听到的 Key 写入数据库或 MQ 做二次保障
• 事件不是精确时间点：Redis 的过期检查是概率性扫描+惰性删除，实际通知可能比 TTL 到期晚几十毫秒到几秒，无法替代高精度定时任务
• 重复消费风险：网络抖动或重连可能导致同一条过期消息被投递多次，监听器逻辑必须是幂等的（例如用数据库唯一约束或状态机校验）