Redis内存占用过高排查方法与内存淘汰机制设置指南

Redis 大 Key 通常是指 Value 体积过大，例如 String 超过 10KB、集合类型元素数量超过 5000 等；这类 Key 往往会引发内存分布不均、性能下降、网络阻塞以及主从复制同步风险。排查时更推荐使用 redis-cli --bigkeys 做采样扫描，而不是直接全量遍历。

redis-cli 里查不出大 Key，别硬扫

如果直接用 redis-cli 连接 Redis 实例，先执行一遍 KEYS *，或者依赖 SCAN 把所有 key 逐个扫描出来，再挨个用 MEMORY USAGE 统计大小，实际效果通常并不好：不仅效率很低，还可能阻塞主线程。特别是当 key 数量超过 10 万以后，这种排查方式基本就不具备实际操作价值了。更棘手的是，MEMORY USAGE 对某些复杂数据结构的统计并不完全准确，比如 field 数量很多的 HASH，返回结果就可能存在偏差，进而影响对 Redis 大 Key 的判断。

更高效、也更适合线上排查的方式，是先放弃逐个精确测量，改为采样扫描 + 分类统计：

• 用 redis-cli --bigkeys 快速找出疑似大 Key（会按数据类型分组统计最大的 key，适合做大 Key 排查，不建议直接全量遍历）
• 配合 redis-cli --memkeys（Redis 7.0+）或第三方工具如 redis-rdb-tools 解析 RDB 文件，进一步查看更准确的 Redis 内存占用分布
• 如果已经明确业务模块，优先检查高频写入的 key 前缀，例如 user:session:*、cache:report:*，再有针对性地执行 MEMORY USAGE

maxmemory 设置不生效？检查配置加载路径和运行时状态

如果你在 redis.conf 中配置了 maxmemory 2gb，但通过 redis-cli INFO memory 看到 used_memory_human 明显超过这个值，通常说明 Redis 内存限制配置并没有真正生效。常见原因主要有三个：

• redis-server 启动时没有指定当前配置文件，实际加载的可能仍是默认配置（检查启动命令是否带了 -c /path/to/redis.conf）
• 配置被运行时命令覆盖：例如执行过 CONFIG SET maxmemory 0（表示取消内存限制），需要通过 CONFIG GET maxmemory 确认当前生效值
• 在 Docker 容器环境中配置挂载失败：检查 docker inspect 输出中的 Mounts，确认是否真的映射到了容器内的 /usr/local/etc/redis/redis.conf 路径

验证方法并不复杂：执行 redis-cli CONFIG GET maxmemory，返回值必须是非零正整数，而且单位是字节（例如 "2147483648" 就表示 2GB）。

allkeys-lru 不等于“自动清理”，它只在写操作触发时才淘汰

即使设置了 maxmemory-policy allkeys-lru，但 Redis 内存仍持续增长，也不代表淘汰策略失效，而是因为它的触发条件没有满足。LRU 内存淘汰机制通常只会在以下场景下生效：

• 当新的写入命令（如 SET、HSET、LPUSH）导致内存即将超出 maxmemory 限制时，Redis 才会主动淘汰旧 key
• 读操作（如 GET、HGETALL）不会触发淘汰，即使当前内存已经接近或达到上限也一样
• 如果业务流量几乎都是读请求，或者写入频率非常低，那么 Redis 淘汰机制就会处于“沉睡”状态，内存自然不会主动下降

因此，不能把它理解为类似 GC 的定时自动清理机制。如果发现 Redis 内存长期处于高位却没有明显回落，就要进一步确认是否存在持续写入，以及淘汰后是否又被新数据快速填满。这时还需要检查业务逻辑是否反复写入同一批 key，或者 key 设计本身存在问题，例如把大量日志数据持续堆积到一个 LIST 中。

volatile-* 策略要求你主动设过期时间，否则无效

如果选择了 volatile-lru，却发现没有任何 key 被淘汰，大概率不是 Redis 配置异常，而是因为这些 key 根本没有设置过期时间。volatile-* 系列淘汰策略只会作用于已经设置了 EXPIRE 或 PEXPIRE 的 key，其他未设置过期时间的 key 会被视为“永久数据”，不会参与淘汰。

检查方法很直接：执行 redis-cli TTL some_key，如果返回 -1（永不过期）或 -2（key 不存在），那它都不是当前策略下的淘汰目标。临时补救方案可以是批量补充过期时间：

redis-cli --scan --pattern "user:*" | xargs -n 1 -I {} redis-cli EXPIRE {} 3600

但更重要的还是从代码层面保证写入时就携带过期时间，例如配合 EXPIRE，或者直接使用 SETEX，而不是等到内存上涨后再被动修补。

Redis 内存占用过高最难处理的地方，往往不在于配置项本身，而在于“淘汰”和“过期”其实是两套彼此独立的机制——前者解决空间问题，后者控制数据时效；两者叠加后，最终行为取决于是否同时满足各自的生效条件，比如既需要写操作触发淘汰，又要求 key 本身带有过期时间。只要漏掉其中任意一环，Redis 内存淘汰机制就很容易形同虚设。