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。
