结论是：没有通用最优策略，选错比不设更危险；noeviction用于缓存会导致写失败，volatile-ttl误用于长期配置会刚写入就被清除；maxmemory需结合数据生命周期设定，预留10%~20%余量，优先用config set动态配置；volatile-lru仅淘汰带ttl键，allkeys-lru可兜底但可能误删冷配置；volatile-ttl仅适用于纯时效性场景，易因忽略访问频次而误淘汰热点长ttl键。

直接说结论：没有“通用最优策略”，选错策略比不设更危险——比如把 noeviction 用在缓存场景，一满就写失败；把 volatile-ttl 用在长期有效配置项上，可能刚写入就被清掉。

怎么配 maxmemory 才不算拍脑袋

内存上限不是越大越好，也不是越小越省。关键看你的数据生命周期和访问模式：

• 先查当前实际使用量：INFO memory 看 used_memory_human 和 mem_fragmentation_ratio
• 预留 10%~20% 余量：避免因碎片或突发写入触发淘汰抖动
• 别设成机器总内存的 80%：Redis 进程本身、AOF/RDB、复制缓冲区都要吃内存
• 线上建议用命令动态设：CONFIG SET maxmemory 2gb，比改配置文件重启更安全

volatile-lru 和 allkeys-lru 到底该选哪个

区别不在“L”（Least）上，而在“volatile”这个限定词是否成立：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 如果你所有缓存 key 都明确设置了 EXPIRE 或 SETEX，且没有长期有效的元数据（比如用户权限白名单），volatile-lru 更安全——它只动“临时数据”，不会误删你没设过期时间但实际需要保留的 key
• 如果你混用了带 TTL 的业务缓存 + 不带 TTL 的配置类 key（比如 app:config:feature_flags），又不想手动管理哪些该设过期，allkeys-lru 是唯一能兜底的选择，但必须接受“冷配置也可能被踢”的风险
• volatile-lfu 在 Redis 4.0+ 可用，适合识别真正热点（比如首页商品 ID 被反复查），但要注意 LFU 计数器有衰减机制，刚写入的 key 不会立刻被保护

为什么 volatile-ttl 容易被误用

它看起来很合理：“快过期的先删”，但实际常导致反效果：

• 它只看剩余 TTL，不管访问频次——一个刚写入、TTL 剩 1 秒的 key，哪怕被高频访问，也会优先被淘汰
• 适合场景非常窄：比如短信验证码（TTL 固定 5 分钟）、临时会话 token（TTL 30 分钟），且这些 key 绝对不参与热点竞争
• 如果业务里存在“长 TTL + 高频访问”的 key（如用户头像 URL 缓存设了 7 天 TTL），volatile-ttl 会把它当垃圾清掉，缓存命中率断崖下跌
• 错误典型：把 SET key val EX 3600 和 SET key2 val2 EX 60 放一起，结果 key2 每分钟都在被优先淘汰，而 key 却一直留着

生产环境最容易被忽略的三个点

策略生效的前提条件常被跳过：

• maxmemory 必须是正整数，设为 0（默认值）等于没开淘汰机制，noeviction 就是摆设
• 用 CONFIG SET 修改策略后，要立刻执行 INFO memory 确认 maxmemory_policy 已更新，某些旧版本 Redis 不支持热 reload 策略
• 淘汰不是实时触发的：只有在写命令（如 SET、HSET）导致内存超限时才启动，读操作不会触发淘汰——所以监控要盯紧 evicted_keys 指标，而不是等报错才发觉