Redis怎样只淘汰设置了过期时间的缓存

应选择 volatile-lru（或 volatile-lfu、volatile-ttl、volatile-random）策略，因其仅在已设置过期时间的 key 中淘汰，完全跳过永不过期的 key；需确保 key 真正设置了 EXPIRE 或带 EX/PX 的 SET，否则不被视为 volatile。 Redis 的 maxmemory-policy 怎么选才只淘汰带过期时间的 key Redis 默认不会区分 key 有没有设置 或 ，只要内存超限，所有策略都可能删掉永不过期的 key。想“只淘汰设置了过期时间的 key”，唯一靠谱的策略是 （或对应的 、 、 ）。这些策略的关键词是 前缀——它明确表示：只在已设置过期时间的 key 中做淘汰，完全跳过 的 key。 ：在带过期时间的 key 里，淘汰最近最少使用的 ：不管有没有过期时间，全盘参与淘汰 → 不符合需求 ：内存满直接报错 → 不淘汰，也不满足 配置方式很简单，在 里写： 或者运行时动态改： 为什么 策略有时看起来“没起作用” 常见现象：开了 ，但内存还是爆了，甚至发现永不过期的 key 被删了——这基本可以断定：你根本没真正设过期时间。 Redis 判断一个 key 是否属于 “volatile” 的唯一依据，是它内部是否存有 字段。用 写入的 key，默认没有这个字段，哪怕你之后用 加了过期时间，它就变成 volatile；但如果你用 ，效果一样，也进 volatile 集合。 容易踩的坑： 会移除过期时间，这个 key 就立刻退出 volatile 集合，后续内存紧张时它就“免疫”淘汰，但也会导致你以为“怎么不删它”，其实是它已经不算 volatile 了。 另一个盲区：用 、 等命令写入的数据，如果没显式调用 ，它们就永远不是 volatile key，哪怕你业务逻辑里“本意是临时缓存”。 如何快速验证哪些 key 属于 volatile 类型 Redis 没有直接命令列出所有带过期时间的 key，但可以用组合方式排查： 查单个 key： 返回正数（剩余秒数）→ 是 volatile；返回 → 没设过期时间；返回 → key 不存在 批量检查（适合低流量环境）： 配合 脚本，例如用 Lua： （注意：生产环境慎用大范围 SCAN，会阻塞） 更实用的办法：在业务写缓存时统一加监控日志，记录哪些 key 调用了 或带 / 的 ，比事后扫描更可靠。 设置过期时间本身也有陷阱 过期时间不是“保险丝”，它和淘汰策略是两套机制：过期是被动清理（惰性+定期），淘汰是主动驱逐（内存压不住时）。所以即使你每个 key 都设了 ，若 用的是 ，照样可能删掉刚设完过期时间的 key。 和 效果等价，但后者是原子的，避免 成功后 失败导致 key 永久残留 过期时间设为 0？ 等价于立即删除，不是“不过期” 使用 时传错毫秒时间戳（比如误用秒级 Unix 时间），会导致 key 在 1970 年就过期，实际效果是“写进去就没了” Redis 的 volatile 策略只看有没有过期元数据，不看过期时间还剩多少、是不是快到了。真正容易被忽略的，是开发时随手写的 —— 它永远不会进 volatile 集合，无论你心里觉得它“应该临时存在”。