登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  数据库 >  Redis

Redis 内存淘汰策略怎样观察被淘汰的键

来源:17golang原创

时间:2026-11-02 07:59:46 378浏览 收藏

我排查 Redis 缓存命中率突然下降时,最先想知道的不是“内存满了吗”,而是到底哪些键被淘汰了。结论是:实时看键名,用 keyevent 通知订阅 __keyevent@0__:evicted;判断是否持续发生,用 INFO stats 的 evicted_keys 做累计核对。两者要一起看,单看其中一个都不够。

官方地址:https://redis.io/

要点速览
  • notify-keyspace-events 使用 Ee 才能把淘汰事件发到 keyevent 频道。
  • evicted_keys 是实例启动以来的累计计数,不提供被淘汰的键名。
  • Redis Pub/Sub 是即时通知,断线期间的事件不会补发;Cluster 要按节点订阅。

一、先确认 maxmemory 与淘汰策略

Redis 只有在配置了内存上限、并且策略允许淘汰时,才会因为 maxmemory 触发键淘汰。先读取当前配置,避免把 TTL 到期误判成内存淘汰:

# 读取实例的内存上限和淘汰策略,先确认观察对象
redis-cli CONFIG GET maxmemory maxmemory-policy

# 读取内存与累计淘汰计数,记录观察开始前的基线
redis-cli INFO memory
redis-cli INFO stats | grep '^evicted_keys:'

allkeys-lru、allkeys-lfu 等策略可以从所有键中选择淘汰对象;volatile-* 只在带过期时间的键中选择。若策略是 noeviction,写入超限时通常会返回内存错误,不会产生你要监听的 evicted 事件。

观察项回答的问题不要误读为
maxmemory-policy超限时采用哪种选择规则已经淘汰了多少键
evicted_keys实例累计淘汰过多少键当前被淘汰的键名清单
expired 事件键因 TTL 到期被删除内存压力导致的淘汰

二、用 keyevent 通知实时看到淘汰键名

Redis 的通知默认关闭。这里不启用所有事件,只开启两类:E 表示 keyevent 频道,e 表示因 maxmemory 产生的 evicted 事件。配置可以临时设置,也可以写进配置文件并随实例重启保留。

Redis maxmemory-policy、notify-keyspace-events 与 evicted keyevent 的静态关系图
图1:Redis 内存上限和通知配置之间的静态关系,展示 Ee 如何把淘汰键名送入 keyevent 频道;这是说明图,不是运行截图。
# 只开启 keyevent 通道和 evicted 事件,减少无关通知
redis-cli CONFIG SET notify-keyspace-events Ee

# 订阅 0 号库的淘汰事件,消息内容就是被淘汰的键名
redis-cli --csv SUBSCRIBE '__keyevent@0__:evicted'

另开一个终端制造足够的缓存写入后,订阅端会收到类似下面的消息。第二列是频道,最后一列才是键名:

"message","__keyevent@0__:evicted","cache:user:10086"
"message","__keyevent@0__:evicted","cache:product:sku-9"

不要把 expired 和 evicted 混为一谈。前者表示过期删除,后者表示为了满足 maxmemory 策略而释放键;如果业务同时使用 TTL 和内存淘汰,监控上应该分开计数。

三、用 INFO stats 把实时事件变成可复查指标

实时订阅适合知道“刚刚是哪一个键”,但它不会替你保存历史。把开始观察时的 evicted_keys 记下来,结束时再读一次,用差值判断窗口内淘汰量:

# 记录窗口起点的累计值,输出可保存到监控采集器
redis-cli INFO stats | awk -F: '/^evicted_keys:/{print $2}'

# 观察结束后再次读取;两次结果的差值就是窗口内的增量
redis-cli INFO stats | awk -F: '/^evicted_keys:/{print $2}'

例如起点是 1200、终点是 1276,只能说明这段时间新增了 76 次键淘汰,不能从这个计数反推出具体键名。生产监控里可以把该字段作为单调计数器,结合每秒增量、命中率、内存使用和写入错误一起判断是否需要调整缓存容量或淘汰策略。

Redis evicted_keys 累计计数与 evicted 实时键名事件的静态对应关系图
图2:实时 evicted 事件提供键名,INFO stats 提供累计数量,两条观察线共同解释一个淘汰窗口;这是结果示意图,不是运行证据。

四、断线、Cluster 与生产环境的边界

keyspace notification 基于 Redis Pub/Sub,订阅客户端断开时,期间的消息不会排队补发。因此它适合实时诊断和轻量指标,不适合作为“所有淘汰记录都不能丢”的审计日志。需要可靠留痕时,应在应用侧记录缓存重建、降级和关键键的业务日志,并把 evicted_keys 作为总量对账。

Redis Cluster 的通知是节点本地事件,不会自动广播到所有节点。要观察整个集群,需要在每个主节点建立对应订阅,并分别读取每个节点的 INFO stats。配置修改也要确认是对哪个节点生效,不能只在一个节点执行后就认为全局完成。

最后,通知本身会消耗 CPU。排障时可以临时打开 Ee,长期运行则只保留确实需要的事件,并控制订阅端处理速度;不要为了看一个淘汰键而打开 KEA 这类大范围事件集合。

相关问题

Redis 的 evicted_keys 为什么一直是 0?

先确认实例确实设置了非零 maxmemory,策略不是 noeviction,并且写入压力曾经超过可用上限;单纯设置了 TTL 不会增加这个字段。

只订阅 expired 能看到内存淘汰吗?

不能。expired 只对应 TTL 到期删除,内存淘汰要开启 e 事件并订阅 __keyevent@数据库号__:evicted。

如何保存所有被淘汰的键名?

不能只依赖 Pub/Sub。它没有断线补发能力;如果键名留痕是硬要求,应让订阅程序尽快写入独立的日志或消息系统,同时保留 evicted_keys 做数量核对。

Redis Cluster 为什么只看到部分淘汰事件?

因为通知按节点产生且不广播。需要逐个连接集群主节点订阅,并分别汇总节点级计数。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>