redis不会同时批量删除大量过期key，而是通过惰性删除+定期删除分散压力；但大量key集中过期会导致过期key滞留内存，触发maxmemory限制下的淘汰机制，造成内存突增、evicted_keys飙升及oom错误。

Redis 不会“同时”批量删除大量过期 key，而是靠定期 + 惰性策略分散压力；但若大量 key 集中过期，仍可能触发内存淘汰（maxmemory 限制下的 maxmemory-policy）——这不是过期策略失效，而是内存不足的兜底行为。

为什么大量 key 同时过期会导致内存压力突增？

Redis 的定期删除默认每秒执行 10 次（由 hz 配置控制），每次最多检查 20 个设置了过期时间的 key。即使所有 key 都在同一秒内过期，Redis 也不会在那一秒全删掉——它只按节奏随机抽查。结果就是：大量过期 key 滞留在内存中，直到被惰性删除（下次访问时才删）或下一轮定期删除抽中。

如果这批 key 占用内存很大，而 Redis 又启用了 maxmemory 限制，就会立刻触发内存淘汰机制，而不是等过期清理完成。

• 常见现象：used_memory_human 突然飙升，evicted_keys 计数快速上涨，客户端出现 (error) OOM command not allowed when used memory > 'maxmemory'.
• 关键点：过期 ≠ 立即释放内存；内存释放滞后，但 maxmemory 是硬上限，不讲情面。

如何避免集中过期引发的淘汰风暴？

核心思路是「错峰」——让过期时间带随机扰动，避免整点/整分批量到期。

Redis Skill - 高性能缓存管理

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

下载

• 写入时加随机偏移：比如业务要求缓存 30 分钟，实际设为 expire key (1800 + rand(0, 300))（即 ±5 分钟扰动）
• 避免用固定时间戳批量设置：expireat 或 pexpireat 如果都用同一个时间戳（如取整到分钟），极易造成雪崩
• 对批量 key 使用不同 db 或命名空间无法规避问题——过期检查是跨 db 随机遍历的，db 隔离不解决集中过期

当淘汰已发生，怎么确认是过期堆积导致的？

查两个指标比看日志更直接：

• 运行 info keyspace，观察各 db 的 expires 字段是否远大于 keys（说明大量 key 已过期但未删）
• 运行 info memory，重点关注：mem_fragmentation_ratio（若接近 1 说明碎片不高，问题不在分配器）、expired_keys（累计过期 key 数）、evicted_keys（已淘汰数）——若后者突增而前者增长缓慢，说明是内存满触发淘汰，不是过期清理慢

注意：expired_keys 是累计值，不能反映当前堆积量；真正要看的是 redis-cli --stat 中 expired 行的实时增量速率。

调整配置能缓解，但不能根治

可微调，但有代价：

• 增大 hz（如调到 100）：让定期删除更频繁，但 CPU 占用上升，官方明确建议不超过 100
• 增大 maxmemory-samples（如从默认 5 改为 10）：让 LRU/TTL 淘汰更准，但每次淘汰耗时略增
• 改用 volatile-ttl 策略：优先淘汰马上过期的 key，适合 TTL 集中场景，但对长尾过期无效

最易被忽略的一点：哪怕你把 hz 调到 100、maxmemory-samples 调到 20，只要写入端没做随机化，过期 key 依然会在同一秒被 redis 抽中——只是抽中的批次变多、间隔变短，本质仍是“延迟释放”，而非“同步清除”。