Redis内存淘汰策略与过期策略是分阶段协同的两层防线：过期策略负责清理已设TTL的key（惰性+定期删除），淘汰策略在内存达maxmemory时按策略驱逐key；前者只作用于带过期时间的key，后者依配置决定作用范围，二者分工明确、不可替代。

Redis内存淘汰策略和过期时间不是互斥机制，而是分阶段协同工作的两层防线：过期策略负责“该删的删”，淘汰策略负责“不够用时删谁”。两者共存且有明确分工，不配合好就容易出现内存打满、写入失败或大量过期 key 滞留。

过期策略只管“是否该删”，不管“删不删得掉”

Redis用expireIfNeeded()在访问时检查 key 是否过期，再配合定期随机抽查（由hz和maxmemory-samples控制）来清理。但这两个动作都只针对设置了过期时间的 key —— 没设过期时间的 key 根本不会被过期策略盯上。

这意味着：

• 即使你把maxmemory设得很小，只要 key 全是永不过期的，过期策略完全不触发，淘汰策略也还没到启动时机
• 如果大量 key 设置了过期时间但长期没人访问，惰性删除不生效；而定期删除又只抽样（默认每 100ms 查 5 个），漏掉的过期 key 就卡在内存里不动
• ttl返回-1表示没设过期时间，-2表示 key 不存在 —— 别靠ttl判断 key 是否“有效”，它只反映过期配置状态

内存淘汰策略在“写入时”才真正介入

淘汰策略不是后台定时任务，而是在每次执行写命令（如set、hset）前，Redis 检查当前内存是否超过maxmemory。超了，才按maxmemory-policy选 key 删除。

Redis Skill - 高性能缓存管理

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

下载

关键点在于：

• noeviction是默认策略，内存满后直接返回(error) OOM command not allowed when used memory > 'maxmemory'，写操作全挂
• volatile-*类策略（如volatile-lru）只从带过期时间的 key 里挑，如果此时内存里全是永不过期 key，哪怕它们占了 99% 内存，淘汰策略也“视而不见”，照样报错
• allkeys-lfu和allkeys-lru会无差别扫描所有 key，但代价是更重的 CPU 开销，尤其在 bigkey 多的场景下可能拖慢响应

常见误配导致的线上问题

很多故障不是因为策略本身有问题，而是过期时间和淘汰策略没对齐：

• 缓存层用了volatile-ttl，但业务代码忘记给 key 设过期时间 → 所有 key 都不进淘汰候选池 → 写入阻塞
• 用setex设了 5 分钟过期，但实际业务访问间隔常超 10 分钟 → 惰性删除失效 + 定期删除抽样漏掉 → 过期 key 堆积 → used_memory持续上涨
• 把hz从默认 10 调到 100 想“更快删过期 key”，结果单线程 Redis 在高并发下频繁被拉去干清理活，latency毛刺明显上升
• 用allkeys-random应对突发流量，但没意识到它完全不看访问频次或 TTL → 可能刚缓存的热点数据被随机干掉，命中率断崖下跌

怎么让两者真正配合起来

核心原则是：让过期策略尽量“清得动”，让淘汰策略只做兜底。

• 对有明确生命周期的数据（如 session、验证码），必须用setex或expire显式设过期时间，别依赖应用层清理
• 避免混用永不过期 key 和有过期时间的 key —— 如果必须共存，优先选allkeys-*类淘汰策略，否则 volatile 策略形同虚设
• 监控expired_keys（定期删除删掉的 key 总数）和evicted_keys（淘汰策略删掉的 key 总数），如果前者长期为 0 或极低，说明过期策略没起效；如果后者暴涨，说明内存压力已传导到淘汰层，得查是不是过期设置不合理或maxmemory太小
• maxmemory-samples别盲目调大，默认 5 是平衡点；超过 20 就容易在单次检查中卡住主线程，尤其 key 总量超百万时

最易被忽略的一点：persist命令会移除过期时间，但不会触发淘汰策略重新评估 —— 如果你在大促期间临时persist了一批 key 来保命，之后又忘了恢复过期逻辑，这些 key 就彻底脱离两层保护，变成内存黑洞。