volatile-ttl 是 Redis 唯一支持按剩余过期时间优先淘汰的策略，仅作用于 ttl > 0 的已设过期键，每次内存不足时淘汰一个最接近到期的 key，非批量清理、不主动扫描、不保证全量精确排序。
volatile-ttl 是唯一正解
Redis 本身不提供“按剩余过期时间排序后淘汰”的通用策略，但 volatile-ttl 就是专为这个场景设计的：它只在设置了过期时间的键中，挑 ttl 值最小（即最接近到期） 的那个淘汰。不是“即将到期的多个”，而是每次只选一个——但它的行为逻辑就是“越快过期，越优先被踢”。
为什么 volatile-ttl 不等于“批量清理临期键”
很多人误以为开了 volatile-ttl 就会自动扫一遍所有快过期的 key 并清掉一批。其实不是：volatile-ttl 是内存淘汰策略，只在 写入新数据触发内存不足时才启动，且每次只淘汰一个 key（或少量，取决于实现细节），目标是腾出足够空间让当前命令成功执行。它不会主动扫描、也不会提前“防患于未然”。
- 它不干预惰性删除和定期删除对过期键的常规清理
- 它不管没设过期时间的 key（
allkeys-*系列才管） - 它不保证“绝对最短 ttl”，因为 Redis 用的是采样 + 近似比较，不是全量排序
配置和验证要一起做
光改配置不够，得确认生效且符合预期：
- 修改
redis.conf中的maxmemory-policy volatile-ttl，重启或用CONFIG SET maxmemory-policy volatile-ttl - 用
INFO memory查看maxmemory_policy字段是否已更新 - 用
INFO stats观察evicted_keys是否增长，并配合redis-cli --scan --pattern "*"+TTL手动抽样比对被删 key 的 ttl 值是否确实偏小
注意：如果业务里大量 key 的 EXPIRE 时间设得非常集中（比如统一设了 60s 后过期），volatile-ttl 在高并发写入时可能连续淘汰一批 ttl≈0 的 key，看起来像“批量清理”，但这只是巧合，不是机制保障。
容易踩的坑：ttl 为 -1 或 -2 的 key 会被跳过
volatile-ttl 只处理 ttl > 0 的键。如果某个 key 被 PERSIST 过、或原本就没设过期时间、或已被定期删除/惰性删除判定为过期（此时 TTL 返回 -2），它就直接从候选池里剔除了——哪怕你刚给它 EXPIRE 但还没来得及刷新状态，也可能被漏掉。
更隐蔽的是：Redis 的 ttl 命令返回值含义：
-
-1：key 存在但没过期时间 -
-2：key 不存在 或 已逻辑过期（但尚未物理删除） -
>0：剩余秒数，这才是volatile-ttl真正比较的对象
所以如果你发现某些“明明快到期”的 key 没被优先淘汰，先 TTL keyname 看一眼返回值——不是所有“快到期”都算数。
