Redis内存淘汰策略由maxmemory-policy配置决定，不设则默认noeviction导致写入失败；需结合数据TTL、访问模式及一致性要求选择volatile-lru、allkeys-lru等策略，并确保maxmemory非零、淘汰触发条件满足。
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、访问是否集中、能不能接受误删——这些没法靠配置项自动推断。 
