缓存失效主要由淘汰策略与过期时间叠加引发雪崩，而非淘汰策略单独导致；volatile类策略因漏设ttl、集中过期及采样误删热key风险极高，allkeys-lfu配合采样调优与过期抖动更稳定。

缓存失效不是淘汰策略直接导致的，而是策略+过期时间叠加触发的雪崩

Redis 本身不会因为启用了 allkeys-lfu 或 volatile-lru 就“主动让缓存失效”；真正出问题的，是淘汰策略在内存压力下批量误删热 key，或与集中过期形成共振。比如你用 volatile-lru，但凌晨 2 点批量写入的 10 万个商品缓存全设了 EXPIRE key 3600，一小时后整批过期——此时 Redis 内存刚好打满，volatile-lru 开始扫描淘汰，结果刚被访问过的热商品 key 被随机采样命中并删掉，数据库瞬间被打穿。

volatile-xxx 策略实际风险比想象中高

很多人选 volatile-lru 是图“只动带 TTL 的 key”，但漏设 TTL 的后果很隐蔽：

• 没加 EXPIRE 的配置类 key、用户 session key（忘了设 ttl）会永久驻留内存，挤占空间
• 一旦内存触顶，Redis 自动 fallback 到 allkeys-lru 或 allkeys-lfu 兜底，把本该保留的热数据也清掉
• volatile-ttl 更危险：它优先删“马上过期”的 key，等于加速雪崩节奏——本来还剩 30 秒的 key 被第一个删，反而让后续请求更早穿透到 DB

真实线上案例里，70% 的大面积失效都源于 volatile-* 策略 + 漏设 TTL + 固定过期时间三者叠加。

Redis Skill - 高性能缓存管理

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

下载

allkeys-lfu 是当前最稳的默认选择

它不依赖是否设了 TTL，只按访问频次淘汰，天然保护高频 key，且对突发流量干扰小。但必须配合以下调整：

• maxmemory-policy allkeys-lfu —— 明确启用
• maxmemory-samples 10 —— 默认是 5，采样太少易误判；调到 10 能显著降低冷热 key 识别偏差
• 禁用 volatile-ttl，哪怕业务真需要“快过期先删”，也改用应用层定时清理 + 延迟队列替代
• 所有 SET / SETEX 操作必须带随机抖动：Java 用 ThreadLocalRandom.current().nextInt(300)，Python 用 random.randint(0, 300)，避免整点/整分集体失效

光改配置不够，得靠监控和拦截兜底

再好的策略也防不住代码里一句 DEL pattern* 或定时任务误执行 KEYS * + DEL：

• 开启慢日志：slowlog-log-slower-than 10000，重点盯 del、flushdb、eval
• 定期查 INFO memory 中的 evicted_keys 增速，突增说明淘汰已成常态，不是偶然事件
• SDK 层拦截高危命令：对 DEL、FLUSHALL 做白名单校验，或改用 SCAN + 批量 UNLINK

复杂点在于：淘汰不是独立事件，它永远和过期时间分布、写入节奏、采样随机性耦合在一起。一个没加抖动的 SETEX，可能三个月都没事，某天流量峰值+内存碎片一起到来，就直接崩盘。