Redis TTL 怎样区分过期时间不存在与已清除

Redis TTL 返回 -1 时，键仍存在，只是没有关联到期时间；返回 -2 时，键在本次查询时不存在。移除了到期时间不等于清除了键：前者通常表现为 -1，后者表现为 -2。单次 TTL 无法区分键是自然过期、被删除，还是从未创建。

官方地址：https://redis.io/docs/latest/commands/ttl/

把查询工具限定为当前状态判断

做一个最小的 TTL 状态查询工具即可解决大多数误读：输入一个键名，输出原始整数、单位和状态名称，不根据负数猜测历史原因。以下语义适用于 Redis 2.8 及以后版本；更旧版本不能按同样规则区分两种负值。

TTL 的单位是秒，PTTL 的单位是毫秒，两个负值的状态含义一致。需要观察临近到期的短时间窗口时优先读取 PTTL，但精度更细也不会让结果成为未来保证。查询完成后键仍可能发生变化。

准备独立的过期状态样本

使用已安装 redis-cli 的独立测试实例；下面命令默认连接本机默认端口。若实例需要不同地址或认证，使用所在环境已有的受控连接配置，不把密码写入文章或共享命令历史。先确认三个样本键均不存在；存在任何一个就停止，改用自己未占用的测试前缀并同步替换后续命令。

# 仅查询测试键，期望总数为 0；非 0 时不要执行后面的写入
redis-cli EXISTS demo:ttlstate:plain demo:ttlstate:timed demo:ttlstate:absent

# NX 避免覆盖现有键；第二个样本自带 120 秒到期时间
redis-cli SET demo:ttlstate:plain sample NX
redis-cli SET demo:ttlstate:timed sample EX 120 NX

# absent 样本刻意不创建，用于观察不存在的状态
redis-cli TTL demo:ttlstate:plain
redis-cli TTL demo:ttlstate:timed
redis-cli TTL demo:ttlstate:absent

两次 SET 都应成功才继续。无其他写入时，plain 应为 -1，absent 应为 -2，timed 在到期前是非负秒数。实际数字取决于命令间隔；如果超过 120 秒才查询，timed 也可能已是 -2。这些是供读者复现的预期，本文未在本机执行 Redis 实验。

用原始整数保留三种返回语义

工具的核心是保留原始整数，再做互斥分类，而不是用“所有负数都算缓存失效”的判断。下面是集成到客户端适配层的 Python 纯分类函数，不绑定具体 Redis SDK：

def classify_ttl(raw, unit):
    # 适配层必须传入 Redis 原始整数，不能传 duration 或空值映射
    if type(raw) is not int:
        raise TypeError("需要原始整数返回值")
    if unit not in ("seconds", "milliseconds"):
        raise ValueError("需要明确时间单位")

    # 两个特殊值分别判断，0 仍保留为剩余时长状态
    if raw == -2:
        state = "missing"
    elif raw == -1:
        state = "no_expiry"
    elif raw >= 0:
        state = "expiring"
    else:
        raise ValueError("未知 TTL 返回值")

    return {"state": state, "raw": raw, "unit": unit}

客户端的高级方法可能把返回值转换为时长、空值或布尔值。接入前应阅读该客户端对应方法的约定；如果已丢失 -1 与 -2 的区别，应改用保留原始整数的接口，而不是把转换后的数值直接交给这个函数。

对照持久键与临近到期键

对 timed 执行 PERSIST 是“移除到期时间”，不是“删除键”。在该样本仍存在且仍带到期时间的条件下，PERSIST 返回 1，后续 TTL 变为 -1。若返回 0，可能是键已经不存在，也可能是本来没有到期时间，不能仅凭 0 判断具体原因。

# 在测试样本到期前移除其到期时间，不会删除值
redis-cli PERSIST demo:ttlstate:timed
redis-cli TTL demo:ttlstate:timed

# 只给本次测试样本恢复短到期时间；生产键不要照抄
redis-cli PEXPIRE demo:ttlstate:timed 1500
redis-cli PTTL demo:ttlstate:timed
redis-cli TTL demo:ttlstate:timed

这些查询不是同一瞬间的快照。秒级 TTL 返回 0 不等于不存在；毫秒级 PTTL 更适合看短暂剩余时长，但下一个独立请求依然可能得到 -2。不要用一个固定正数作为验收结果，也不要为了“确认缺失”反复重置键的到期时间。

接入业务时保留错误与采样时间

正式集成只需要一个只读查询入口：记录目标实例、数据库、键标识、命令名、采样时间、原始整数、单位与状态。日志中避免保存敏感键内容；凭据不属于诊断输出。异常应单独报告为查询失败，不能把超时、认证错误、连接中断统统映射成 missing。

对单个键读取 TTL 或 PTTL 已能区分这两种当前状态，无须先 EXISTS 再 TTL。额外 EXISTS 可以辅助人工查看，却无法把两个独立请求拼成一致快照：例如 EXISTS 后键恰好到期，随后 TTL 返回 -2 并不矛盾。多条命令分开采样时要保留各自的时间与结果，不编造“同一时刻”的联合结论。

若需要追问“是谁清除了键”，那是另外一个历史观测问题；当前 TTL 返回值没有删除者、删除原因或历史到期设置字段。没有历史记录就应写“原因未知”，不能从 -2 倒推出已过期。

用状态清单核对并清理样本

最小工具的完成标准是：-2 与 -1 分别呈现；0 不被误判为缺失；TTL 和 PTTL 带明确单位；异常不冒充有效状态；缺失原因保持未知。测试样本按前缀隔离，操作结束仅清理本次实际创建的两个键。

# 删除不可撤销；仅在确认是本次独立实验样本后执行，禁止换成业务键或通配符
redis-cli DEL demo:ttlstate:plain demo:ttlstate:timed

TTL 为 -1，数据是不是已经没了？

不是。它描述的是键存在但无到期时间，不表示缺失，也不承诺永远保留。

TTL 为 -2，能确认曾经设置的到期时间已到吗？

不能。它只描述本次查询时键不存在；具体历史原因需要另外的观测记录。

只用 PTTL 能替代 EXISTS 吗？

只为区分当前键缺失、无到期时间和带到期时间这三种状态时，可以直接解释原始 PTTL 返回值；不要把这个结果扩大为随后的业务读取保证。

命令说明：TTL、PTTL、PERSIST。