Redis TTL 为何返回负数

Redis 的 TTL 返回负数，通常不是命令失效，而是在告诉你键的生命周期状态：-1 表示键存在但没有设置过期时间，-2 表示键已经不存在。只有大于等于 0 的结果才表示还剩多少秒；如果需要毫秒精度，应使用 PTTL。

本文只围绕这个排查任务展开，示例命令用于说明判断方式，不把未执行的输出写成实测证据。

官方文档：https://redis.io/docs/latest/commands/ttl/

先把负数分成两类：看到 -1 查过期策略，看到 -2 查键是否存在以及是否已被删除或自然过期。

先记住 TTL 的三类返回值

TTL key 的结果可以先按下面的速查表理解：

这三个结果不要混成一个“负数异常”。-1 的重点是“键还在但永久保存”，-2 的重点是“查询时已经没有这个键”。下面的结构说明图把命令、键和结果分组展示出来。

用带过期时间和不带过期时间的键对照

最小对照实验只需要三个键生命周期动作。下面的命令按顺序表达“设置过期时间、移除过期时间、删除键”，输出仍应以文档定义为准。

# SET EX 同时写入值和 60 秒过期时间，TTL 会返回接近 60 的正数
redis-cli SET demo:ttl "active" EX 60
redis-cli TTL demo:ttl

# PERSIST 保留值但移除过期时间；此时键存在，TTL 应返回 -1
redis-cli PERSIST demo:ttl
redis-cli TTL demo:ttl

# DEL 删除键；再次查询时 TTL 应返回 -2
redis-cli DEL demo:ttl
redis-cli TTL demo:ttl

如果业务代码使用的是 SET 的普通形式、后续又没有调用 EXPIRE，那么键返回 -1 是符合预期的。反过来，调用 PERSIST 后，原来的倒计时也会被移除，不是 TTL 计算错误。

第二张图强调的是生命周期关系：值本身、过期元数据和键是否存在是三个相关但不同的判断点。

按判断顺序排查负数

线上遇到负数时，先不要立刻重写缓存代码，可以按“键是否存在→是否有过期时间→写入路径是否覆盖”的顺序检查。为了让分支一眼可读，可以把判断写成下面的 shell 片段：

# 先读取 TTL，再区分键不存在和永久键；这是排查逻辑示例
ttl=$(redis-cli TTL demo:ttl)

if [ "$ttl" -eq -2 ]; then
    # -2 说明查询时没有这个键，检查键名、DEL 或自然过期
    echo "key-not-found"
elif [ "$ttl" -eq -1 ]; then
    # -1 说明键存在但没有过期时间，检查 EXPIRE/PERSIST 路径
    echo "no-expiration"
else
    # 非负值表示剩余秒数，数值越小越接近过期
    echo "seconds-left=$ttl"
fi

这段示例没有处理网络错误、认证失败或客户端的本地解析差异；生产代码应单独检查命令退出状态，并把“Redis 请求失败”与“Redis 返回 -1/-2”分成不同告警。

在精度和并发场景下收住边界

TTL 的单位是秒，短时缓存如果需要更细粒度，可以用 PTTL 获取毫秒级剩余时间。两条命令的负数语义仍然对应“无过期时间”和“键不存在”，但它们都只反映查询发生的那个瞬间。

# PTTL 返回毫秒；先写入 1500 毫秒过期时间，再读取剩余毫秒数
redis-cli SET demo:short "active" PX 1500
redis-cli PTTL demo:short

# 查询与使用之间可能经过一段时间，不要把 TTL 结果当成永久锁
redis-cli TTL demo:short

如果一个进程刚检查完 TTL，另一个进程就删除了键，那么后续读取失败并不矛盾。需要原子地完成“检查并操作”时，应把操作边界设计在合适的 Redis 命令或脚本中，而不是依赖两次独立查询之间的时间窗口。

常见问题

TTL 返回 -1 是不是缓存失效？不是。它表示键存在，只是当前没有过期时间；是否符合业务预期要看写入路径。

TTL 返回 -2 一定是键名写错吗？不一定，也可能是键自然过期、被 DEL 删除，或查询与写入使用了不同的数据库、前缀或实例。

为什么 TTL 有时从 1 直接变成 -2？TTL 以秒返回，键可能在两次查询之间过期；查询结果不是锁，也不是对未来状态的承诺。

记住一条实用顺序即可：-1 查过期元数据，-2 查键是否存在，正数再处理剩余时间和精度问题。