Redis TTL 为什么会变成 -1

Redis TTL 返回 -1 表示键仍存在，但没有关联的过期时间。原本有倒计时的键突然变成 -1，优先检查是否被普通 SET 覆盖、是否执行过 PERSIST，以及创建键后设置 EXPIRE 的步骤是否遗漏或失败。它不表示“已经过期”；键不存在时，现代 Redis 的 TTL 返回 -2。

对于字符串缓存，最直接的修复通常是把有效期与写入合在同一条 SET 中，例如 SET key value EX 120。如果业务要求更新值但保留原截止时间，则选择 KEEPTTL；它不会给原本没有过期时间的键补上倒计时。

Redis 官方地址：https://redis.io/

下面做一个只含一个字符串缓存键的小例子。读者需要可连接的测试 Redis 与 redis-cli；所有命令为示例，不是本文实际运行记录。使用独立测试键，不要直接覆盖生产缓存。

给缓存小例子定义三种过期状态

项目目标是让 demo:ttl:profile:run01 在更新后仍满足约定的生命周期。需要同时考虑缓存值与过期元数据，而不是只判断 GET 能否读到内容。

TTL 是秒级信息，不能要求两次读取结果精确一致。需要更细的观察可使用 PTTL，但单位变为毫秒，不能把正常毫秒数当成秒数。也不要把负数统一取绝对值后显示成剩余时间。

复现普通 SET 覆盖带来的变化

# 只在独立测试环境写入专用样例键；EX 的单位是秒
redis-cli SET 'demo:ttl:profile:run01' 'draft-v1' EX 120
redis-cli TTL 'demo:ttl:profile:run01'

# 普通 SET 更新字符串值时没有携带过期策略，已有有效期会被清除
redis-cli SET 'demo:ttl:profile:run01' 'draft-v2'
redis-cli TTL 'demo:ttl:profile:run01'

在没有其他请求干预的情况下，第一处 TTL 应是剩余秒数，普通覆盖后的 TTL 应为 -1。这里描述预期语义，没有给出固定倒计时或伪造控制台输出。

另一个常见来源是把 SET 和 EXPIRE 写成两次独立请求。第一条成功、第二条因进程退出、异常分支或调用遗漏未完成时，键会留下无过期状态。只检查 SET 成功不足以证明缓存生命周期已建立。

PERSIST 也会主动移除键的过期时间。相反，INCR、LPUSH 和对已有 Hash 字段执行 HSET 这类不整体替换键内容的操作通常保留键的过期时间；不能把所有“更新”都归为会清除 TTL 的同一种行为。对于 Hash，还要区分整键有效期与字段有效期，本文讨论的是 TTL key。

选择重新计时还是保留原截止时间

先决定更新是不是一次刷新。每次刷新都允许延后120秒，则每条写入都带 EX：

# 更新值并重新设置本次写入的有效期
redis-cli SET 'demo:ttl:profile:run01' 'draft-v3' EX 120
redis-cli TTL 'demo:ttl:profile:run01'

如果原截止时间不能延后，例如更新缓存展示字段但仍沿用原有效窗口，可保留已有过期设置：

# 只有键存在才更新，并保留原过期时间；XX 未满足时不会写入
redis-cli SET 'demo:ttl:profile:run01' 'draft-v4' XX KEEPTTL
redis-cli TTL 'demo:ttl:profile:run01'

KEEPTTL 从 Redis 6.0 起提供，部署前确认实际服务端与客户端接口支持。它保留的是已有状态：若键存在但已经没有过期时间，执行后仍可能返回 -1。XX 只限制键必须存在，也不保证它原先有有效期。

EX 和 KEEPTTL 是不同的过期策略，不要放进同一条 SET。若已有键被发现为 -1，必须先按业务重新建立有效期或重新装载内容，不能期待保留选项自动修复缺失信息。

把修复接入所有写入入口

集成时将“值 + 有效期策略”作为统一写入接口的参数，让创建、刷新、降级回填和后台任务都走同一约定。常见遗漏是主请求使用 EX，后台补偿路径却调用普通 SET，于是问题只在部分请求后出现。

故障修复期间，不建议不加区分地给所有无过期键批量加120秒。部分键本就设计为长期存在，业务缓存也可能需要不同有效期。应先确认键角色、当前值的新鲜度和所有写入方。

下面仅演示给本文专用样例键补回有效期。EXPIRE 返回是否成功设置，键已不存在时不能将失败当成修复成功。检查后再修改是两条请求，并不保护并发写入；生产修复需要结合实际写入一致性方案。

# 仅针对本文测试键恢复生命周期，不用于批量修改未知业务键
redis-cli EXPIRE 'demo:ttl:profile:run01' 120
redis-cli TTL 'demo:ttl:profile:run01'

记录时保留键的业务类别、写入命令类型、是否携带过期参数和错误分支即可；没有必要把完整缓存内容写进排障日志。若监控持续出现 -1，沿写入入口查找覆盖行为，比在定时任务里反复补 EXPIRE 更接近根因。

用状态清单判断修复是否完整

一个完整的小例子应覆盖四个判断：首次 SET EX 后有倒计时，普通 SET 后没有过期时间，重新 SET EX 后重新计时，XX KEEPTTL 更新后保留原有效窗口。读者运行时需同时查看写入回执，不能只对着某一次 TTL 猜测前面发生了什么。

TTL 变成 -1 是 Redis 持久化出错了吗？

这个返回值本身只说明当前键没有过期设置，不能直接归因于持久化。先查普通覆盖、PERSIST 和设置有效期的调用是否完成。

为什么刚查到正数，再查却是 -2？

两次读取之间键可能自然过期或被删除。TTL 读取是当时状态，并不是锁定键的承诺。

KEEPTTL 能保证新键一定过期吗？

不能。它没有提供新的过期时长；需要为新键建立生命周期时，应明确使用 EX、PX 等符合业务的参数。

完成测试后，只清理本例专用键：

# 确认没有其他用途后删除本文测试键
redis-cli DEL 'demo:ttl:profile:run01'

官方参考：TTL 返回值、SET 过期选项、EXPIRE 与有效期保留规则。