Redis淘汰机制结合Pub/Sub实现LRU本地缓存同步方案

时间：2026-08-20 20:08

Redis 的 LRU 淘汰机制不会触发 Pub Sub 事件，只有键过期事件（需配置 notify-keyspace-events Ex）才能被监听；如果要实现缓存同步失效，应依赖 TTL + keyspace notification，而不是依赖 LRU 淘汰策略。Redis 本身并没有真正意义

Redis 的 LRU 淘汰机制不会触发 Pub/Sub 事件，只有键过期事件（需配置 notify-keyspace-events Ex）才能被监听；如果要实现缓存同步失效，应依赖 TTL + keyspace notification，而不是依赖 LRU 淘汰策略。

如何利用Redis淘汰机制实现简单的LRU本地缓存同步_通过Pub/Sub监听

Redis 本身并没有真正意义上的“本地缓存同步”能力。它的 LRU 淘汰策略只在单个 Redis 实例内部生效，无法把淘汰结果跨进程、跨服务传播出去。如果想依靠 maxmemory-policy allkeys-lru 来触发 Pub/Sub，通知其他节点“这个 key 刚刚被淘汰了”，实际上是不可行的，因为 Redis 不会为内存淘汰事件发布消息。

Redis 的 LRU 淘汰不会触发任何 Pub/Sub 事件

这是一个非常常见的误区。很多人以为只要开启了 allkeys-lru，当 key 被移除时就能通过订阅机制收到通知。但事实并非如此。像 DEL、EXPIRE、EVICT 这类底层行为里，Redis 默认不会针对淘汰动作对外广播。只有在 key 明确进入过期流程，且启用了 keyspace notifications 的情况下，Redis 才会向 __keyevent@__:expired 频道发送消息。需要注意的是，淘汰（eviction）和过期（expiration）并不是一回事，两者的实现机制彼此独立。

EXPIRE / SET ... EX → 可能触发 expired 事件（前提是配置了 notify-keyspace-events Ex）
LRU 淘汰 → 全程静默，没有 channel、没有日志、也没有回调通知
即便使用 redis-cli --stat 看到 evicted_keys 持续增长，也无法得知究竟是哪个 key 被淘汰

想同步“被 LRU 踢掉的 key”，得自己埋点拦截

如果你确实需要让其他服务感知“某个 key 已经从当前 Redis 缓存中消失”，就不能依赖自动淘汰，而应该绕开 LRU 机制，改用显式可控的失效方式：

不要依赖自动淘汰，改为使用带 TTL 的 SET key value EX 300 主动设置过期时间
提前开启 keyspace notifications：执行 CONFIG SET notify-keyspace-events Ex（也可以写入 redis.conf）
订阅 __keyevent@0__:expired 频道（注意 db 编号必须一致）
收到消息后，解析 payload（即 key 名），再通过自定义 channel（如 cache-evict-broadcast）使用 PUBLISH 转发给其他节点

示例监听逻辑（Python）：

import redis
conn = redis.Redis()
pubsub = conn.pubsub()
pubsub.subscribe('__keyevent@0__:expired')

for msg in pubsub.listen():
if msg['type'] == 'message':
key = msg['data'].decode()
# 这里不是淘汰，是过期；但语义上可当作“缓存失效”处理
conn.publish('cache-invalidation', key)