Redis 内存淘汰怎样观察真实驱逐原因

Redis 里一个 key 消失，不一定是内存淘汰。要观察“真实驱逐原因”，我会把一次排查拆成三条证据链：INFO stats 看累计的驱逐和过期计数，INFO memory 看是否触碰 maxmemory，INFO keyspace 看数据库中有多少 key 带 TTL。Redis 官方地址：https://redis.io/。

先把驱逐、过期和拒写分开

Redis 的 key 消失有三种常见路径。第一种是命中 maxmemory 后按策略移除 key，evicted_keys 会增加；第二种是 key 自己的 TTL 到期，expired_keys 会增加，但这不属于 maxmemory 驱逐；第三种是策略为 noeviction，Redis 保留已有数据并拒绝需要继续占用内存的写命令。

因此，单看某个 key 已经不存在，无法还原原因。更可靠的做法是先保存一份快照，等待几分钟，再保存第二份，比较两个累计计数器的差值。累计值很大只说明实例从启动以来发生过很多事件，增量才说明当前窗口正在发生什么。

用 INFO 三组指标还原原因

先记住下面这组最小字段，排查时不需要一开始就抓取整份 INFO everything。

判断可以按这个顺序做：若 evicted_keys 在窗口内增加，并且 used_memory 接近 maxmemory，基本可以确认发生了 maxmemory 驱逐；若只有 expired_keys 增加，应优先检查 TTL 设计。两者都增加，说明主动过期与内存压力同时存在。若计数不变却出现写入 OOM，检查 maxmemory_policy 是否为 noeviction，以及是否把客户端淘汰误看成 key 淘汰。

做一个可重复的观测小工具

下面的脚本只抓关键字段，适合在同一实例上连续执行并保存两份文本。它不修改 Redis 配置，也不会重置统计。

#!/usr/bin/env bash
# 读取内存、统计和 keyspace 的最小字段，便于前后快照做差值。
set -u

# 读取单个 INFO 字段；字段不存在时返回空值，避免误报。
info_value() {
  local section="$1" key="$2"
  redis-cli --raw INFO "$section" | awk -F: -v wanted="$key" '$1 == wanted {print $2; exit}'
}

# 这些累计计数必须和下一次快照相减，不能直接当作当前速率。
printf 'time=%s\n' "$(date -u +%FT%TZ)"
printf 'used_memory=%s\n' "$(info_value memory used_memory)"
printf 'maxmemory=%s\n' "$(info_value memory maxmemory)"
printf 'maxmemory_policy=%s\n' "$(info_value memory maxmemory_policy)"
printf 'evicted_keys=%s\n' "$(info_value stats evicted_keys)"
printf 'expired_keys=%s\n' "$(info_value stats expired_keys)"
printf 'current_eviction_exceeded_time=%s\n' "$(info_value stats current_eviction_exceeded_time)"

# keyspace 的 db 编号按实例实际使用情况调整；没有 db0 时只会得到空结果。
redis-cli --raw INFO keyspace | awk '/^db0:/{print}'

如果两次快照相隔五分钟，evicted_keys 从 1200 变成 1260，就可以说这个窗口至少发生了 60 次 key 驱逐；不能据此说有 60 个业务请求失败，也不能从累计值推导精确的每秒速率。要估算速率，还需要记录快照时间并用增量除以时间间隔。

几个容易把结论带偏的边界

used_memory 与操作系统 RSS 不是同一个数。删除 key 后分配器可能暂时不把页面还给操作系统，所以 RSS 仍高，不等于 Redis 此刻还在持续驱逐。另一方面，mem_not_counted_for_evict 代表不计入 key 驱逐判断的内存，复制缓冲区等场景会让“进程很满”和“已经开始驱逐”并不同步。

副本默认不执行和主节点相同的 key 驱逐，主节点发生的删除会通过复制传播；排查集群时要明确你查看的是主节点还是副本。还有一个常见混淆是 evicted_clients：它统计的是达到 maxmemory-clients 后被移除的客户端连接，不是被淘汰的业务 key。

常见问题

只看 evicted_keys 能判断哪个 key 被删了吗？

不能。它是累计数量，不包含业务 key 名称。需要结合应用访问日志、key 命名和采样监控追查具体对象；本文只用它判断是否发生过驱逐。

expired_keys 增加是不是说明内存淘汰策略生效？

不是。它说明 TTL 到期事件增加。带 TTL 的 key 可能在没有内存压力时自然过期，也可能与 maxmemory 驱逐同时发生。

为什么 used_memory 没超过 maxmemory，仍然看到驱逐计数增加？

先看时间窗口和字段更新时间，再检查瞬时峰值、内存统计口径以及是否读到了另一台实例。当前值已回落，不代表窗口内没有短暂越过边界。

这套方法的核心不是给 Redis 加更多探针，而是把“当前边界”和“窗口增量”放在一起：先确认策略，再看 evicted_keys/expired_keys 的变化，最后用 keyspace 的 TTL 比例解释业务行为。