Redis过期事件监听不实时的根本原因是其采用“删除时通知”而非“到期触发”机制，依赖惰性删除与定期删除策略，存在固有延迟；Pub/Sub无重传、不保序、断连丢消息；集群模式下事件完全不可用。
Spring Boot监听Redis过期事件不能保证消息实时性，根本原因不在Spring Boot，而在Redis本身的过期机制设计——它压根就不是“到点触发”，而是“删的时候才通知”。
Redis过期不等于准时删除
你调用 SET order:123 "pending" EX 1800，只是给key打了个“30分钟后该删”的标签。Redis不会启动一个精准计时器，而是靠两种策略被动清理：
- 惰性删除：等下次有人
GET order:123时，才检查是否过期，过期就顺手删掉 - 定期删除：每秒随机抽查20个key（默认配置），删掉其中已过期的
这意味着：如果这个key一直没人访问，又没被抽查到，它可能在内存里多活几秒甚至几十秒。只有真正被删的那一刻，Redis才会发 __keyevent@0__:expired 消息——监听器收到的永远是“删除完成时间”，不是“过期设定时间”。
Pub/Sub本身不保序、不重传、不确认
Spring Boot通过 RedisMessageListenerContainer 订阅频道，底层走的是Redis原生Pub/Sub，它有三个硬伤：
- 客户端断连超过1秒，期间所有
__keyevent@0__:expired消息直接丢弃（无缓冲、无重发） - 消息只发一次，
onMessage回调里抛异常或处理失败，不会重试 - 多个实例同时订阅同一频道，同一个过期key会触发N次处理（需自行加幂等）
哪怕Redis配置了 notify-keyspace-events Ex 且网络完全正常，也解决不了这层语义缺失。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
Spring Boot封装进一步掩盖延迟来源
很多人用 KeyExpirationEventMessageListener，觉得“框架都帮你包好了”。但它只是把原始 Message 解析成 String key，不做任何时间戳校验或延迟补偿。你拿到的 key 字符串，和它实际过期的时间差，可能已经累积了：
- Redis定期删除的扫描间隔（默认100ms一次）
- 消息从Redis内核发到客户端TCP缓冲区的排队时间
- Spring容器线程调度+反序列化开销（尤其高并发时）
实测中，30秒TTL的key，监听器平均收到时间在30.2~31.5秒之间波动，长尾可达35秒以上。
集群模式下彻底失效
如果你用的是Redis Cluster，__keyevent@0__:expired 频道根本收不到任何消息。因为Cluster协议规定：键空间通知只在key所在的具体分片节点上触发，而客户端连接的是Cluster入口（如JedisCluster），无法自动订阅所有分片的对应频道。现象就是本地单机跑得好好的，一上生产集群就静默——连错误日志都不会打。
真正容易被忽略的是：这个限制无法绕过，哪怕你手动遍历所有节点去订阅，也会因reshard、failover导致事件丢失。业务关键路径（比如支付关单）必须放弃这条路，改用ZSET+定时轮询或Redis Stream+ACK兜底。
