内存淘汰策略本身不防雪崩，但配错会加剧雪崩：maxmemory-policy仅在内存满时触发，而雪崩多因大量key同时过期或redis宕机引发，此时策略未生效；volatile-ttl等错误配置反而加速集中失效，noeviction则导致写入失败引发重试风暴。

内存淘汰策略本身不防雪崩，但配错会加剧雪崩

Redis 的 maxmemory-policy 淘汰策略，和缓存雪崩没有直接防御关系。它只在内存满时起作用，而雪崩通常发生在大量 key 同时过期（TTL 到期）或 Redis 宕机时——这两个场景下，内存未必满，淘汰策略根本不会触发。

但错误配置会放大雪崩后果：比如用了 noeviction，内存满后写失败，新数据进不来；或者用了 volatile-ttl，刚好把一批快过期的热点 key 先删了，反而加速失效节奏。

• volatile-lru 和 allkeys-lru 在高并发重建缓存时可能误删正在被读的 key，导致二次穿透
• volatile-random 有概率提前删掉还没过期但“运气差”的 key，破坏预期失效分布
• 如果业务大量使用带 TTL 的 key，又配了 volatile-* 类策略，那过期 + 淘汰双重清理，更容易出现空窗期

真正起作用的是 TTL 设计，不是淘汰策略

防止雪崩的核心动作是控制 key 失效时间的分布，而不是靠内存不够时删谁。重点在写入缓存那一刻就打散过期时间。

常见错误是批量调用 EXPIRE key 3600，所有 key 都卡在整点过期。正确做法是加随机偏移：

Redis Skill - 高性能缓存管理

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

下载

• 基础过期时间设为 3600 秒，再加 random.nextInt(600)（0–10 分钟），实际 TTL 落在 3600–4200 秒之间
• 避免用固定时间戳如 EXPIREAT key 1752400000，否则集群内所有实例 key 同时到期
• 对同一类数据（如商品详情），不同 ID 的 key 必须独立计算随机 TTL，不能复用同一个值

哪些淘汰策略可以配合雪崩防护一起用？

虽然淘汰策略不防雪崩，但在雪崩发生后，合理的策略能减缓连锁恶化。关键看是否保留重建机会：

• allkeys-lfu 相对友好：它倾向保留访问频次高的 key，哪怕没设 TTL，也能让热点数据多留一阵，给缓存重建争取时间
• volatile-lru 风险较高：如果大量热点 key 都设了 TTL，它会优先淘汰“最近少用但还没过期”的 key，反而把刚加载的冷数据留下
• 绝对不要用 noeviction：雪崩期间数据库压力大，应用拼命往 Redis 写新缓存，内存满直接报 (error) OOM command not allowed when used memory > 'maxmemory'，连补救机会都没了

生产环境必须检查的三个配置项

光调策略不够，得确认它们真实生效：

• maxmemory 是否已设置？未设置等于没启用淘汰机制，内存无上限，OOM 风险远高于雪崩
• maxmemory-policy 是否为 allkeys-lfu 或 allkeys-lru？volatile-* 类策略在无 TTL key 较少时基本无效
• 用 INFO memory 查 mem_used_human 和 maxmemory_human，确认当前内存使用率是否稳定在 70% 以下——超了说明淘汰已频繁触发，需查日志里 evicted_keys 计数

雪崩真正的防线在 TTL 分布和降级兜底，淘汰策略只是最后一道缓冲。别让它成为压垮系统的最后一根稻草。