redis过期事件非实时触发，仅在键被真正删除时发布__keyevent@0__:expired消息，存在延迟且不保证100%送达；需显式配置notify-keyspace-events ex，spring boot需正确配置redismessagelistenercontainer并指定精确频道名。
Redis过期事件监听不是实时触发，而是“删除时通知”
Redis的__keyevent@0__:expired消息不是在TTL归零那一刻发出的，而是在键**被真正删除时**才发布——这可能延迟几毫秒到几秒，尤其在内存压力大、使用惰性删除+定期删除混合策略时。这意味着你不能把它当成精确计时器用，比如“订单30分钟整准时关单”这种需求，实际关闭时间可能晚于30分钟。
- Redis不保证过期事件100%送达：若订阅客户端断连、消息积压或Pub/Sub缓冲区满，事件会直接丢失（无重发机制）
- 事件只带
key名，不带value、过期时间、数据库编号以外的任何上下文 - 如果你依赖该事件做关键业务（如支付关单），必须配合兜底机制（例如定时扫描+状态校验）
必须开启 notify-keyspace-events 配置，且仅限 Ex 或 AKE
默认情况下，Redis完全不发送任何键空间事件。光改代码没用，notify-keyspace-events这个配置项必须显式启用，否则__keyevent@0__:expired频道永远收不到消息。
- 最小安全配置是
notify-keyspace-events Ex：E 表示 keyevent 类型，x 表示 expired 事件 - 别用
AKE或gxE等宽泛组合——它会广播 del、expire、rename 等所有操作，大幅增加网络和CPU开销，尤其在高写入场景下容易压垮监听服务 - 修改后需重启 Redis 或执行
CONFIG SET notify-keyspace-events "Ex"（注意：该命令在部分云托管Redis中被禁用）
Spring Boot 中监听需配 RedisMessageListenerContainer + TopicPattern
Spring Data Redis 的 RedisMessageListenerContainer 默认不自动订阅过期事件，必须手动注册监听器并指定频道模式。直接 new 一个 MessageListener 并扔进去是无效的。
- 频道名必须严格为
__keyevent@0__:expired（数字0替换成你的目标db编号）；不能写成__keyevent@*:expired—— Redis 不支持通配符订阅跨库事件 - 如果要用正则匹配 key 名（例如只处理
order:*过期），得在 onMessage 回调里自己做key.startsWith("order:")判断，Redis 层不提供 pattern-filtering - 监听器 Bean 必须声明为
@Component或通过@Bean注入容器，且container.setConnectionFactory(...)后必须调用container.afterPropertiesSet()（Spring Boot 2.4+ 自动处理，但低版本需显式）
Jedis/Redisson 直连方式要注意连接隔离与重连逻辑
用原生 Jedis 或 Redisson 手动 subscribe 时，最容易出问题的是连接生命周期管理——Pub/Sub 连接不能复用普通命令连接，且断线后不会自动重订阅。
- Jedis：必须用独立的
JedisPubSub实例 + 单独的Jedis订阅连接，不能拿JedisPool里的连接去subscribe（会阻塞整个连接池） - Redisson：要用
getPatternTopic("*")而非getTopic("__keyevent@0__:expired")，否则无法收到消息；且必须主动调用addListener并确保 listener 实现PatternMessageListener - 所有直连方案都得自己实现断线重连 + 重订阅逻辑，否则一次网络抖动就永久失联
最常被忽略的一点：过期事件只在键被删除时触发，而 Redis 删除键的时机不可控。如果你的实例设置了 maxmemory + allkeys-lru，那么一个 key 可能因内存驱逐被删，此时发的是 e 事件（not x），除非你把 notify-keyspace-events 配成 Eex，否则根本收不到通知。
