redis 7.0 的 maxmemory-policy 不能防止缓存雪崩，它仅是内存满时的淘汰机制，不干预过期时间分布；雪崩主因是大量 key 同时自然过期，此时策略尚未触发，且 volatile-ttl 等反而会加剧集中失效。
Redis 7.0 的 maxmemory-policy 不能防止缓存雪崩
直接说结论：maxmemory-policy 是内存不足时的“保命机制”，不是防雪崩策略。它只在 Redis 内存打满后触发淘汰，而缓存雪崩通常发生在大量 key 自然过期（还没到内存上限）的瞬间——此时 maxmemory-policy 根本不生效。
常见误解是：设了 allkeys-lru 就能“自动打散压力”。但 LRU/LFU 类策略依赖访问热度，对批量写入后集体静默的场景（如预热商品页缓存）完全无效；volatile-ttl 看似相关，但它只淘汰“已设置过期时间且剩余 TTL 最短”的 key，若所有 key 的 TTL 都被设成同一值（比如全设为 3600），它反而会集中清掉一批 key，加剧雪崩。
哪些淘汰策略在雪崩场景下会恶化问题
以下配置在高风险业务中应避免：
-
volatile-ttl：TTL 集中时，它会把同一秒到期的 key 批量踢出，放大穿透流量 -
allkeys-random/volatile-random：随机性不可控，可能误删热点 key，导致后续请求全部击穿 -
noeviction（默认）：内存满后直接报错OOM command not allowed when used memory > 'maxmemory'，虽不淘汰，但会让写入失败，引发上游重试风暴
真正需要的是可预测、低干扰的行为：比如优先淘汰冷数据，或明确排除热点 key。但 Redis 7.0 原生淘汰策略里没有“按写入时间排序淘汰”或“保留最近 N 分钟写入的 key”这类能力。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
唯一可依赖的“可预测”策略：allkeys-lru + 合理的 maxmemory 预留
如果必须从内置策略中选一个相对可控的，allkeys-lru 是目前最接近“可预测”的选项，但前提是满足两个硬条件：
- 业务写入模式稳定：key 有持续访问，LRU 链表能真实反映冷热
-
maxmemory设置低于物理内存上限至少 20%：给淘汰过程留出缓冲空间，避免在内存临界点频繁触发大批量驱逐 - 禁用
lazyfree-lazy-eviction no（即保持默认）：确保淘汰动作同步完成，不堆积异步任务影响响应延迟
示例配置片段（redis.conf）：
maxmemory 4gb maxmemory-policy allkeys-lru # 不要开 lazyfree-lazy-eviction yes —— 雪崩场景下异步淘汰可能延迟释放内存，导致后续请求仍被拒绝
真正防雪崩的关键动作不在 redis.conf 里
所有靠 maxmemory-policy “自动兜底”的想法，在生产环境都会失效。Redis 7.0 没有内置机制能把“过期时间分布”这件事交给配置文件管理。你必须在业务代码里做三件事：
- 每次调用
set/setex/SETEX时，显式计算带 jitter 的 TTL，而不是传固定值 - 批量写入必须每个 key 单独生成
jitter，严禁循环外统一算一次再复用 - 对核心链路加
mutex key（如SET lock:product:123 NX EX 5），否则即使 TTL 分散，单个 key 过期时的并发重建仍可能压垮 DB
这些动作无法被配置项替代，也不存在“开了某个开关就安全”的捷径。最容易被忽略的点是：jitter 范围必须与 base TTL 成比例——base 是 1 小时，jitter 设 ±1 秒毫无意义；base 是 1 天，jitter 设 ±1 小时又太激进。这个比例关系，得你自己根据业务毛刺容忍度去调。
