Redis SET NX EX 组合为什么可能覆盖已有 TTL

先给结论：SET key value NX EX 60 本身不会在键已经存在时覆盖旧值或旧 TTL，因为 NX 让这次写入直接失败；但只要一次 SET 真正成功，Redis 默认会把原来的 TTL 丢掉，EX 再给它设置新的过期时间。很多“NX EX 覆盖了 TTL”的问题，实际是把条件写入、普通覆盖和续期写在了不同分支里。

Redis SET 的条件写入和 TTL 到底怎样组合

把这条命令拆开看就不容易误判：

SET lock:order:42 token-a NX EX 30
# NX：只有键不存在才允许这次写入。
# EX 30：写入成功后，把过期时间设置为 30 秒。
# 两个选项分别负责条件和过期策略，不负责互相兜底。

当 lock:order:42 不存在时，返回 OK，键值为 token-a，TTL 约为 30 秒。当键已经存在时，返回空结果，值、旧 TTL 都不应因这次命令改变。真正危险的是另一个场景：应用在别处执行了没有 NX 的成功 SET，或者用“先查再写”模拟条件判断。

用三个键状态判断旧 TTL 是否会被改写

Redis 官方文档对 SET 的默认语义是：成功设置已有键时，旧 TTL 会被丢弃；KEEPTTL 才表示保留与键关联的剩余生存时间。可以用下面的表快速定位。

注意，EX、PX、EXAT、PXAT 与 KEEPTTL 是互斥的过期选项。因此不能指望用 NX EX 30 KEEPTTL 同时表达“创建时设置 30 秒，更新时又保留旧 TTL”。这两个业务意图应该拆成不同命令。

按业务语义选择 NX、XX 与 KEEPTTL

锁初始化通常只允许第一个请求成功，命令可以保持简单：

SET lock:order:42 token-a NX EX 30
# 返回 OK 才能进入临界区；空结果表示锁已被其他请求持有。

如果要在键已经存在时更新值，但不能把倒计时重新拉满，就选 XX KEEPTTL，不要再追加 EX：

SET session:42 refreshed-token XX KEEPTTL
# XX：键必须存在；KEEPTTL：保留写入前剩余的 TTL。
# 返回空结果时，说明键可能已过期或条件不满足。

相反，续租或明确重置租期时，才使用 XX EX 30。这会把过期倒计时重新设为 30 秒，是“续期”而不是“保留 TTL”。客户端代码也应根据返回值记录分支，而不是只判断请求有没有抛异常：

result = redis.set("lock:order:42", token, xx=True, keepttl=True)
# result 为 True 才表示已有键被更新；False 表示条件没有满足。
if not result:
    return "lock_missing_or_expired"
return "updated_without_resetting_ttl"

用 TTL 与 PTTL 检查应用层是否误写

排查时不要只看 SET 返回 OK。在同一条业务链路里记录键名、条件分支、SET 返回值和写入前后的 TTL，才能判断 TTL 是被重置还是条件根本没通过。

TTL lock:order:42
PTTL lock:order:42
# TTL 返回秒，PTTL 返回毫秒；-1 表示没有过期时间，-2 表示键不存在。

如果已有键执行 NX EX 后 TTL 变化，先查是否实际命中了另一条普通 SET、SET XX EX 或续期逻辑，再查是否存在“先 EXISTS/GET、后 SET”的非原子代码。对锁、幂等标记和会话刷新来说，推荐在代码评审中直接写出三种命令意图：

• 只创建：NX EX/PX。
• 只更新且保留剩余时间：XX KEEPTTL。
• 只更新并重新计时：XX EX/PX。

常见问题

NX EX 能不能保留已有键的 TTL？

已有键时因为 NX 条件失败，原 TTL 不会被这次命令改动；但这不是“保留选项”的效果。成功覆盖已有键并保留 TTL，应使用 KEEPTTL。

为什么不能写成 NX EX 30 KEEPTTL？

Redis 的过期选项互斥，EX 和 KEEPTTL 表达了两种不同的租期策略。创建和更新应按业务分支使用不同命令。

TTL 返回 -1 说明什么？

说明键存在但没有设置过期时间；-2 表示键不存在。两者都应结合 SET 返回值一起判断，不能只看一个数字。

参考：Redis SET 官方命令文档。