Redis 过期通知为什么会漏：Pub/Sub 丢失、配置核对与补偿扫描

缓存过期后，业务场景里经常需要收到对应事件，用来删除索引、刷新统计数据或者触发轻量清理操作；但 Redis 的过期通知本身不属于可靠队列。订阅连接断开、配置没开启对应事件，或是把「TTL 清零」误判为「立刻发出 expired 事件」，都可能导致监控里出现漏报。正确的处理思路是把通知当作实时提示，再用可重放的补偿扫描做最终兜底收口。

现场症状：key 已过期，下游却没收到事件

假设订单缓存使用 cache:order:8842，过期后要同步删除对应的检索索引。在 Redis 里用 GET 已经读取不到这个 key，但订阅服务的日志里找不到对应的 expired 消息。这时候不能直接判定 Redis 没执行过期清理，因为「逻辑失效」「产生通知」和「订阅者处理完成」是三条完全独立的链路。

排查的时候先固定四个时间节点：写入 key、TTL 变为负数、Redis 产生事件、消费者落库。如果只记录最后一个时间点，很容易把订阅断线或者处理失败误算成 Redis 丢事件。

先把 Redis 的事件路径理清楚

Redis 会把键空间事件发布到 Pub/Sub 频道。使用键空间通知时，频道形如 __keyspace@0__:cache:order:8842；使用键事件通知时，频道形如 __keyevent@0__:expired，消息体是 key 名。两种方向对应同一类键变化，但订阅模式和解析方式不一样。

这条路径里任意一段出问题，都可能出现「看起来漏了事件」的情况：配置没启用 Ex，订阅者只监听了错误的频道，客户端在重连窗口丢消息，或者消费者收到消息后处理失败却没留重试记录。

用三条命令核对通知配置和事件形态

确认是否启用了过期事件

CONFIG GET notify-keyspace-events
CONFIG SET notify-keyspace-events Ex

配置字符串里的大写 E 代表键事件频道，小写 e 代表过期事件类型；如果要监听键空间频道，可以组合成 KEA，也可以按实际需求选择覆盖范围更窄的集合。生产环境修改配置前先确认托管 Redis 是否允许 CONFIG SET，再把最终配置写入实例管理记录。

用短生命周期 key 观察频道方向

PSUBSCRIBE __keyevent@0__:expired
SET cache:notify:test 1 EX 3
GET cache:notify:test

如果使用键空间频道，就改订阅 __keyspace@0__:cache:notify:test，收到的消息内容是 expired。测试的时候不要等三秒就直接下结论；过期事件的生成受 Redis 自身清理机制影响，验证重点是最终能不能看到事件，以及订阅连接是否全程保持在线。

分别记录 Redis 与消费者的证据

订阅程序至少要记录频道、key、收到时间、处理结果和重试次数；Redis 侧记录实例、数据库编号和配置快照。没有消费日志的话，根本区分不了「没有发布」「发布后断线丢失」和「收到后处理失败」这几种场景。

为什么 Pub/Sub 天生不能当可靠队列

Redis 官方文档明确说明，Pub/Sub 属于发完即忘的模式：订阅客户端断线并重新连接的时候，断线期间的事件不会做补发。它适合实时观察缓存变化、刷新短期指标或者触发低风险动作，但不能独立承载订单状态、库存扣减和账务凭证这类核心流程。

另一个容易混淆的边界是 expired 事件。它只代表 Redis 生成了这个过期事件，不保证刚好在 TTL 到零的瞬间发出；如果 key 长时间没人访问，后台过期处理的调度节奏也会影响事件的实际发出时间。把通知时间当成业务截止时间，会让下游出现提前或者延迟判断的问题。

修复方案：实时通知加一条可重放的补偿线

推荐把处理逻辑拆成两路。第一路订阅 expired 事件，尽快做轻量更新；第二路按时间窗口扫描业务状态表，找出「缓存已过期但索引仍存在」的记录，再执行同一个幂等修复函数。两路操作完成后都写入处理标记，避免重复收到事件时产生重复副作用。

事件到达 -> 校验业务状态 -> 幂等删除索引 -> 记录结果
补偿扫描 -> 找出未收口记录 -> 重用同一处理函数 -> 记录结果

补偿窗口的时长要覆盖订阅服务的最大断线时长，还要留出 Redis 过期事件延迟和任务调度延迟的冗余。不要直接用全库 KEYS 扫描生产实例；在业务侧维护待处理记录，或者用受控的 SCAN 做分片检查，都比一次阻塞式遍历要稳定很多。

上线前的最小验收清单

常见问题：过期通知排查里的几个边界

只配置 e，为什么监听不到消息？

e 只代表 expired 事件类型，不等于已经选择了键事件或键空间频道。还要根据订阅路径加入 E 或 K，并确认频道模式和配置方向保持一致。

订阅者重启后，Redis 会把漏掉的消息补回来吗？

不会。Pub/Sub 本身不保存离线期间的消息，所以必须用补偿扫描或者可持久化的业务记录恢复缺口。

过期通知能直接驱动库存回滚吗？

不建议。库存、支付和订单状态这类场景需要持久化状态、幂等处理和可重试任务；过期通知最多作为加速信号，不能作为唯一事实来源。

总结：把通知当提示，把状态当事实

Redis 过期通知漏收，通常不是单点故障，而是配置、频道、连接和业务处理共同导致的链路问题。先用短生命周期 key 核对事件方向，再记录断线与消费结果，最后用补偿扫描把 Pub/Sub 的天然缺口收住。实时通知负责响应速度，持久化状态和幂等任务负责可靠性，这个边界比单纯调大过期参数要重要得多。