volatile-ttl会加剧雪崩，因其按剩余ttl集中淘汰key，导致缓存层主动清空；应改用volatile-lru等依赖访问行为的策略，并配合ttl随机化、合理maxmemory设置与lazyfree优化。

maxmemory-policy 本身不能防止雪崩式宕机，它只在内存打满后才介入；而雪崩通常发生在大量 key 同时自然过期的瞬间——此时内存可能远未触顶，策略根本不会触发。

为什么 volatile-ttl 会加剧雪崩

很多人以为 volatile-ttl 是“智能清理快到期的 key”，实际它是雪崩放大器：一旦业务批量设置相同 TTL（比如全设 EX 3600），Redis 就会在同一秒集中淘汰成百上千个 key。监控上会看到 expired_keys 和 evicted_keys 曲线同步尖峰，DB 瞬间被打满。

• 该策略不区分访问热度，也不做时间打散，纯按剩余 TTL 排序
• 若 TTL 集中，它比 noeviction 更危险——后者至少只是写入失败，前者是主动清空缓存层
• 无法与随机过期配合：即使你代码里加了随机偏移，只要 Redis 配置了 volatile-ttl，它仍会优先挑 TTL 最短的，而不会“均匀释放”

真正可控的配置组合

没有银弹，但可收敛风险。关键不是选哪个策略，而是让策略行为可预测、低干扰：

Redis Skill - 高性能缓存管理

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

下载

• 用 volatile-lru 而非 volatile-ttl：LRU 至少依赖访问行为，比纯 TTL 更难被批量操作带偏
• 必须显式设 maxmemory，且 ≤ used_memory_peak × 1.3：避免突发写入直接击穿，留出缓冲窗口
• 开启 lazyfree-lazy-eviction yes：淘汰大 key（如含 10 万字段的 hash）时不卡主线程，防止延迟毛刺引发连锁超时
• 禁用 activedefrag no（默认）改为 activedefrag yes：减少碎片导致的“假性内存不足”，避免误触发淘汰

必须检查的三个运行时指标

别等 DB 告警才反应——雪崩前兆就藏在 Redis 自身指标里：

• evicted_keys 每分钟突增 >500：说明淘汰已成规模，不是偶发事件
• expired_keys 出现周期性尖峰（如整点/每小时）：大概率是 TTL 批量设置问题
• mem_fragmentation_ratio >1.5 且 used_memory 波动剧烈：碎片高 + 内存反复腾挪，淘汰效率极低

调完配置后，用 redis-cli --hotkeys 确认真实热点是否集中在少数 key 上——如果 95% 请求落在 5% key，volatile-lfu 比 volatile-lru 更稳；反之则慎用 LFU，它额外消耗 CPU。