Redis 更新值后 TTL 消失时怎么判断命令是否覆盖过期

Redis 里“更新值后 TTL 消失”通常不是过期机制坏了，而是更新命令把旧的过期时间一起替换了。最典型的情况是先执行 SET user:42 profile-v1，再执行普通 SET user:42 profile-v2：第二次成功写入后，key 仍然存在，但它已经没有 TTL。要保留原倒计时，应使用 SET ... KEEPTTL；要重新计算生命周期，则在写入时明确使用 EX/PX，或写入后再调用 EXPIRE。

一、先用 TTL、PTTL 判断 key 到底处于哪种状态

排查时不要只看一次 TTL。它返回的是秒，倒计时会自然向下取整；如果刚设置了 1500 毫秒，连续读取到 1、0 并不代表 TTL 被命令清空。用 PTTL 看毫秒精度，再配合 EXISTS，判断会稳定很多。

SET profile:42 "v1" EX 300
TTL profile:42
PTTL profile:42
EXISTS profile:42

// TTL=-1 表示 key 仍在但没有过期时间；TTL=-2 表示 key 已不存在
// PTTL 用毫秒精度辅助判断短 TTL 是否只是向下取整

二、普通 SET 为什么会让 TTL 消失

Redis 官方命令语义把普通 SET 视为一次成功的值替换：旧值会被覆盖，旧的过期时间也会被丢弃。下面这组命令可以直接解释很多“缓存突然变成永久”的事故：

SET cache:order:42 "draft" EX 600
TTL cache:order:42
SET cache:order:42 "paid"
TTL cache:order:42

// 第二次 SET 没有携带过期选项，成功覆盖值后 TTL 变为 -1
// 这不是 TTL 读错，而是更新命令没有表达“保留旧过期时间”

如果业务只是修改值、希望沿用第一次写入的生命周期，使用 KEEPTTL：

SET cache:order:42 "paid" KEEPTTL

// KEEPTTL 只保留原有过期时间，不会把已经不存在的 TTL 凭空恢复
// 如果 key 在执行前已经过期，SET 会创建一个没有 TTL 的新 key

如果业务规则是“每次刷新内容都重新给 10 分钟”，不要依赖旧 TTL，而要显式写成 SET key value EX 600。这两种语义必须在代码评审和客户端封装里区分开。

三、用更新策略把“保留”和“续期”写清楚

建议把更新操作先归类，再决定命令：

• 内容变更但生命周期不变：使用 SET key value KEEPTTL，并在结果后读取 PTTL 做低成本监控。
• 每次命中都要续期：使用带 EX 或 PX 的 SET，或明确调用 EXPIRE；这属于续期，不是保留。
• 只有在 key 已存在时才更新：配合 XX，避免条件不满足时误创建一个无 TTL 的新 key。
• 写入后才决定过期时间：检查 EXPIRE 返回值；返回 1 说明设置成功，返回 0 通常表示 key 不存在。

// 根据业务语义选择：只更新值时保留倒计时，刷新缓存时重新设置 10 分钟。
if keepLifetime {
	// SET KEEPTTL 防止更新值时意外清除原 TTL。
	return rdb.Set(ctx, key, value, redis.KeepTTL).Err()
}

// 明确刷新生命周期；这里的 10 分钟是新策略，不是旧 TTL 的延续。
return rdb.Set(ctx, key, value, 10*time.Minute).Err()

客户端库的参数名可能是 KeepTTL、keepttl 或 keepTtl，不要只看方法名猜语义，应该确认它最终发出的 Redis 命令是否带有 KEEPTTL、EX 或 PX。

四、TTL 消失和淘汰策略不是一回事

当 TTL=-1 时，key 只是没有关联过期时间，不能直接推出它会被 Redis 立刻淘汰。淘汰由 maxmemory 与 maxmemory-policy 共同决定：volatile-lru、volatile-lfu、volatile-random 和 volatile-ttl 只在带 TTL 的候选中选择；如果没有带过期时间的 key，这类策略的行为会退化为 noeviction。allkeys-lru 等策略则可以从所有 key 中选择。

因此排障顺序应是：先判断 key 是否存在，再判断是否有 TTL，最后查看实际淘汰策略和内存压力。不要把“更新后 TTL 消失”和“内存不足导致 key 被淘汰”混成同一个原因。

CONFIG GET maxmemory-policy
INFO stats

// maxmemory-policy 决定淘汰候选范围；TTL 只能说明 key 的过期元数据
// keyspace_hits 与 keyspace_misses 可辅助观察缓存命中是否发生变化

相关问题

TTL 显示 0 是不是已经没有 TTL？

不是。它可能仍有很短的剩余时间；用 PTTL 看毫秒，随后再用 EXISTS 确认 key 是否已经消失。

SET KEEPTTL 能给新 key 设置过期时间吗？

不能。它只保留已有的 TTL；新 key 没有旧 TTL 时，仍需要 EX、PX 或单独的 EXPIRE。

更新 Hash 字段也会清除整个 key 的 TTL 吗？

应把具体命令单独核对。本文结论针对会替换 key 值的 SET；不要把字符串覆盖语义直接套到所有数据类型命令上。