Redis EXPIRE 怎样只在已有 TTL 时缩短过期时间

如果你的目标是“键已经有 TTL 时才把它缩短”，不要直接把 EXPIRE key seconds LT 当成“已有 TTL 条件”。Redis 的 LT 只比较新旧过期时间，而没有 TTL 的持久化键会被当成无限 TTL，因此它反而可能为持久化键新增过期时间。

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

简单、没有并发修改的场景，可以先用 TTL 判断返回值是否大于 0，再执行 EXPIRE；并发场景应把 PTTL 判断和 PEXPIRE 更新放进同一个 Lua 脚本，只有已有 TTL 且目标时间更短时才更新。

先看 TTL 的三个关键返回值

TTL key 返回的是秒级剩余时间。当前 Redis 文档约定，返回正数表示键存在且有过期时间，-1 表示键存在但没有过期时间，-2 表示键不存在。这里的 -1 和 -2 必须区别对待：前者不能被本题逻辑误改成有 TTL，后者则没有可更新的目标。

# 写入一个带 TTL 的键、一个持久化键和一个不存在的键
redis-cli SET cache:with-ttl "v1"
redis-cli EXPIRE cache:with-ttl 300
redis-cli SET cache:persistent "v1"
redis-cli TTL cache:with-ttl
redis-cli TTL cache:persistent
redis-cli TTL cache:missing

297
-1
-2

实际返回值会随着时间变化，带 TTL 的键不必刚好返回示例中的数字。判断重点是正数、-1 和 -2 三种状态。

EXPIRE LT 到底判断什么

Redis 的命令形式是 EXPIRE key seconds [NX | XX | GT | LT]。这些条件选项彼此互斥，不能把 XX 和 LT 拼成一个命令。LT 的含义是：只有新的过期时间小于当前过期时间时才设置；而没有过期时间的键在这个比较中被视为拥有无限 TTL。

因此，下面两类行为不同：

• 已有 TTL 为 300 秒，执行 EXPIRE key 120 LT：新值更短，更新成功，返回 1。
• 持久化键没有 TTL，执行 EXPIRE key 120 LT：无限 TTL 大于 120 秒，条件成立，键会被新增 120 秒过期时间。

如果你的业务要求是“不能给持久化键增加 TTL”，那么 LT 只能负责“缩短比较”，不能负责“已有 TTL 门槛”。这正是很多缓存续期逻辑出现误判的地方。

没有并发修改时：先 TTL，再 EXPIRE

在单线程脚本、后台维护命令或已经保证没有并发写入的场景，可以先读取 TTL，再根据结果决定是否缩短。下面的例子只接受正数 TTL，并且只在目标 120 秒更短时执行更新。

# 目标是把已有 TTL 缩短到 120 秒，不给持久化键补 TTL
current_ttl=$(redis-cli TTL cache:with-ttl)
if [ "$current_ttl" -gt 120 ]; then
  # LT 再做一次服务端比较，避免目标时间变长
  redis-cli EXPIRE cache:with-ttl 120 LT
else
  # 0 表示没有执行更新：可能没有 TTL，也可能已经足够短
  echo 0
fi

这个写法的限制是检查和更新分成了两次命令。假设第一次读到 300 秒，随后另一个客户端把 TTL 改成 60 秒，原客户端仍可能继续执行更新命令。虽然 LT 会拒绝把 60 秒改成 120 秒，但如果并发方在这段时间删除、重建或替换了键，业务语义就可能发生变化。

并发场景：用 PTTL 和 Lua 原子完成判断

需要把“已有 TTL”与“目标更短”放在一次 Redis 执行单元中时，可以使用 Lua。脚本先读取毫秒级剩余时间 PTTL：正数表示已有 TTL，-1 表示持久化键，-2 表示键不存在。只有正数且新毫秒数更小时，才调用 PEXPIRE。

-- 只有已有 TTL 且目标毫秒数更短时才更新
local current_ttl = redis.call('PTTL', KEYS[1])
local new_ttl = tonumber(ARGV[1])

-- -1 是持久化键，-2 是不存在的键，两者都不能更新
if current_ttl > 0 and new_ttl 

通过 redis-cli --eval 传入键名和新 TTL 时，键名放在 KEYS 区域，参数放在 ARGV 区域。下面把目标 TTL 写成 120000 毫秒，也就是 120 秒。

# KEYS[1] 是待处理的键，ARGV[1] 是新的毫秒 TTL
redis-cli --eval /tmp/shorten-existing-ttl.lua cache:with-ttl , 120000

这个脚本的返回值仍然可以按 Redis 命令的整数返回值理解：1 表示过期时间已设置，0 表示没有更新。Lua 脚本在 Redis 内部连续执行，其他客户端不能插入到 PTTL 和 PEXPIRE 之间，因此比客户端先读后写更适合并发缓存策略。

EXPIRE LT、TTL 判断和 Lua 应该怎么选

还要记住，EXPIRE 的 NX、XX、GT、LT 是互斥选项。不要为了表达“已有 TTL 且更短”而拼接 XX LT；这个组合不是该命令支持的语法。需要同时表达两个条件时，把判断写进 Lua，或者在能够接受竞态的业务边界内由客户端显式处理。

常见问题

EXPIRE LT 能不能保证键原本就有 TTL？

不能。无 TTL 的键按无限 TTL 参与 LT 比较，所以有限的新 TTL 可能被设置成功。

为什么不直接使用 EXPIRE XX？

XX 只检查键已有过期时间，不检查新 TTL 是否更短。它可能把当前 60 秒覆盖成 120 秒；要同时满足两个条件，就需要脚本或可接受竞态的两步逻辑。

TTL 返回 -1 时应该怎么处理？

把它当成持久化键，跳过本次缩短，不要把 -1 当成“无限可更新”的普通数值直接参与业务计算。

什么时候用 PTTL 而不是 TTL？

当过期时间很短、需要毫秒级比较，或业务对边界误差敏感时使用 PTTL 和 PEXPIRE。如果只做粗粒度分钟级策略，TTL 更容易阅读。

总结一下：LT 解决的是“新过期时间必须更短”，不是“键必须已有 TTL”。要保护持久化键不被意外加上过期时间，简单场景先区分 TTL 的正数、-1 和 -2；并发场景则用同一个 Lua 脚本完成 PTTL 判断与 PEXPIRE 更新。