volatile-ttl 策略仅在内存达限且有写入时触发，随机采样已设TTL的key并淘汰其中剩余过期时间最短者，并非主动或精准清理“马上过期”的key。
volatile-ttl 策略本身不会“加速清理濒死缓存”，它只在内存不足时，从已设 TTL 的 key 中挑剩余过期时间最短的淘汰——不主动删、不提前删、不保证删到“马上过期”的那个。
volatile-ttl 淘汰触发条件很苛刻
这个策略只在以下两个前提同时满足时才起作用：
-
maxmemory配置已启用，且 Redis 实际内存使用达到或超过该阈值 - 当前有写入操作（如
SET、LPUSH）触发freeMemoryIfNeeded()内存回收流程
换句话说：key 即使只剩 1 秒 TTL，只要内存没满、没写入，volatile-ttl 就完全不工作。它不是定时器，也不是后台扫描线程。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
为什么你查不到“马上过期”的 key？
Redis 不维护“即将过期 key 的优先队列”。volatile-ttl 的实现逻辑是：每次触发淘汰时，随机采样一批设置了 TTL 的 key（默认 20 个），从中选 ttl 值最小的那个。这意味着：
- 采样是随机的，不是按 TTL 排序遍历，所以无法保证选中“最濒死”的那一个
- 如果这批采样里恰好没有剩余 TTL
-
TTL命令返回-2表示 key 已逻辑过期但尚未物理删除，此时它仍可能被volatile-ttl选中——但你无法靠这个判断“是否濒死”
想真正加快濒死 key 清理，得绕开 volatile-ttl
依赖 volatile-ttl 无法达成“精准加速”，实际可操作的路径只有三条：
- 调高
hz配置（比如从默认 10 改为 100），让activeExpireCycle()更频繁执行定期删除，提高过期 key 被随机抽中并清理的概率 - 用
EXPIREAT或PEXPIREAT统一设置较短、可控的绝对过期时间点，再配合业务层定时任务扫描KEYS pattern+TTL，主动DEL剩余 KEYS 在生产环境慎用） - 改用
volatile-lfu或volatile-lru，把“访问热度”或“最后访问时间”作为主维度，辅以 TTL 过滤——至少能避免长期不访问的濒死 key 占着茅坑
真正容易被忽略的是：volatile-ttl 的“ttl”指的是 redisDb.expires 字典中存储的绝对过期时间戳减去当前时间的结果，而这个字典本身不索引、不排序、不预计算——所有“精准”预期，都建立在对底层数据结构的误判上。
