必须先设置maxmemory，否则淘汰策略不生效；maxmemory默认为0（不限制），此时即使配置maxmemory-policy也不会触发淘汰。
必须先设 maxmemory，否则任何淘汰策略都不生效；不设就等于没开淘汰开关。
配置 maxmemory 和 maxmemory-policy 的两种方式
Redis 不会默认限制内存使用，maxmemory 默认为 0（即不限制），此时即使你配了 maxmemory-policy，也完全不会触发淘汰。
- 修改
redis.conf文件（永久生效）：
取消注释并设置两行：maxmemory 2gbmaxmemory-policy allkeys-lru - 运行时动态设置（临时生效，重启后丢失）：
redis-cli CONFIG SET maxmemory 2gbredis-cli CONFIG SET maxmemory-policy allkeys-lfu - 验证是否生效：
redis-cli CONFIG GET maxmemoryredis-cli CONFIG GET maxmemory-policy，输出应为非空且匹配你设置的值
allkeys-lru 和 volatile-lru 到底选哪个？
关键区别不在“算法”，而在“淘汰范围”——它决定了哪些 key 会被动进淘汰池。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
allkeys-lru：所有 key 都参与 LRU 排名，包括没设过期时间的。适合纯缓存场景（如商品页、用户资料），所有数据都可丢。 -
volatile-lru：只对设置了EXPIRE或SET ... EX的 key 做 LRU 淘汰；没设过期时间的 key 永远不会被删。适合混合场景（如缓存 + 持久任务队列），要保护长期存在的 key。 - 误用
volatile-*策略但大量 key 没设过期时间 → 实际无 key 可淘汰 → 内存持续上涨 → 最终触发noeviction行为（写入报(error) OOM command not allowed when used memory > 'maxmemory'）
为什么 Redis 还是频繁淘汰？常见原因和应对
配置了策略 ≠ 淘汰变少。频繁淘汰本质是“写入速率 > 淘汰释放速率”，或“热点太集中导致 LRU/LFU 失效”。
- 内存设得太小：比如业务实际需要 3GB，却只配
maxmemory 1gb→ 淘汰必然高频。建议先用INFO memory查used_memory_peak，留 20%~30% 余量再设maxmemory。 - 用了
allkeys-random或volatile-random：随机淘汰无法保留热点，可能刚缓存的热 key 下一秒就被删，引发反复回源和写入，形成恶性循环。 - LFU 策略在初期“访问频次未稳定”时表现差：新 key 访问几次就被判低频淘汰。若业务有明显冷热分层且稳定，
allkeys-lfu更优；否则优先用allkeys-lru。 - 客户端批量写入大 value（如 1MB 的 JSON）：单次写入就占满剩余空间，直接触发淘汰。应检查
redis-cli --bigkeys找出大 key，并拆分或压缩。
最易被忽略的一点：maxmemory 是按字节硬限，但 Redis 自身元数据（dict 结构、过期时间存储等）也占内存，实际可用给业务 key 的空间比设置值少 10%~15%。别卡着理论值配，尤其在集群模式下更要预留 buffer。
