Redis多环境内存淘汰配置详解

Redis内存淘汰配置看似只需设置maxmemory和maxmemory-policy两个参数，实则深度耦合业务数据特征与环境需求：开发环境用noeviction早暴露问题，预发环境需按TTL分布选择volatile-lru或allkeys-lru，生产环境则必须规避随机策略、慎用LFU以避免CPU飙升和热点误杀；真正关键的不是“怎么配”，而是理解你的key是否有TTL、访问是否集中、能否容忍非预期淘汰——这些决策无法自动化，却直接决定缓存稳定性与服务可用性。

Redis 内存淘汰策略怎么选：maxmemory-policy 配置项决定行为

Redis 不会自动删数据，除非你明确告诉它“内存满了该踢谁”。maxmemory-policy 就是这个决策开关，它不控制“多少内存”，只控制“超了以后怎么删”。

常见错误是把 maxmemory 设了，却漏配 maxmemory-policy —— 此时 Redis 默认用 noeviction，写入直接报错 OOM command not allowed when used memory > 'maxmemory'，服务看似正常，其实写操作全挂了。

• volatile-lru：只从带过期时间的 key 里挑最久没用的删（适合 session、缓存类场景）
• allkeys-lru：所有 key 都参与淘汰（更激进，适合纯缓存无状态数据）
• volatile-ttl：优先删快过期的（注意：不是“最近设的 TTL”，而是“剩余 TTL 最小”的）
• noeviction：拒绝写入（仅建议开发环境或强一致性要求场景）

不同环境推荐配置：dev / staging / prod 的实际取舍

开发环境常设 maxmemory 256mb + maxmemory-policy noeviction，为的是早暴露 OOM 问题；但上线后必须改掉，否则一压测就崩。

Staging 环境建议模拟生产流量特征：如果业务缓存 key 大部分带 TTL（比如 SET user:123 "xxx" EX 3600），用 volatile-lru 更安全；如果大量用 SETNX 或 INCR 做分布式锁/计数器，这些 key 没 TTL，就得切到 allkeys-lru，否则锁可能永远不被淘汰，内存悄悄涨满。

• prod 环境禁止用 volatile-random 或 allkeys-random：随机淘汰不可控，容易误杀热点 key
• Redis 6.0+ 可启用 maxmemory-samples 10（默认 5），提升 LRU 近似精度，但别盲目调太高，采样开销会上升
• 云托管 Redis（如阿里云、AWS ElastiCache）要注意：有些控制台把 maxmemory 显示为“最大使用内存”，其实是硬限制，不是预留值

淘汰策略生效前必须确认的三件事

光配对策略不够，Redis 还得“知道内存超了”，而这依赖三个条件同时满足。

• maxmemory 必须设为非零值（单位字节，268435456 = 256MB），设成 0 表示不限制
• 内存统计以 used_memory 为准（INFO memory 查），不是 used_memory_rss —— 后者含内存碎片和子进程开销，不能触发淘汰
• 淘汰只发生在写命令期间（SET、LPUSH、HSET 等），读命令（GET、HGETALL）不会触发，也不会主动清理过期 key（惰性删除+定期删除才是过期机制）

为什么 allkeys-lfu 在某些场景反而比 lru 更伤性能

lfu 策略要维护访问频次计数器，每次 key 被访问都要更新（哪怕只是 EXISTS），CPU 开销明显高于 lru。实测在高并发短 key 场景（如 token 校验），QPS 上万时 allkeys-lfu 的 CPU 使用率可能比 allkeys-lru 高 30%+。

更隐蔽的问题是：LFU 计数器有衰减机制（默认每分钟右移一次），如果业务存在周期性低峰（比如凌晨批量任务停摆 2 小时），LFU 会把曾经的热点 key “遗忘”得过快，导致刚回暖就又被淘汰。

• 用 allkeys-lfu 前先跑 redis-cli --stat 看实际访问分布，如果长尾明显（少数 key 占 80%+ 请求），LFU 才有价值
• 可通过 OBJECT FREQ keyname 查单个 key 当前频次，但注意：该命令本身也会计一次访问，别在监控脚本里高频调用
• Redis 7.0+ 支持 maxmemory-policy allkeys-lfu + lfu-log-factor 10 调整衰减灵敏度，factor 越小，历史热度保留越久

配置这事，核心就两行：maxmemory 定上限，maxmemory-policy 定规则。但真正难的是理解你的数据有没有 TTL、访问是否集中、能不能接受误删——这些没法靠配置项自动推断。

终于介绍完啦！小伙伴们，这篇关于《Redis多环境内存淘汰配置详解》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布数据库相关知识，快来关注吧！