内存淘汰策略本身不防雪崩，但配错会加剧雪崩：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 分布和降级兜底，淘汰策略只是最后一道缓冲。别让它成为压垮系统的最后一根稻草。
