Redis EXPIRE 怎样只在新 TTL 更短时更新

我在做缓存刷新时遇到过一个很隐蔽的过期问题：请求 A 给键设置了 60 秒 TTL，请求 B 稍后又按自己的默认值写入 300 秒，结果本来应该尽快失效的数据被意外延长了。Redis 的普通 EXPIRE 会直接更新已有过期时间；如果业务规则是“只接受更短的新 TTL”，应改用 EXPIRE key seconds LT。

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

普通 EXPIRE 为什么会把 TTL 越刷越长

EXPIRE 的默认语义是“把这个键的过期时间改成新值”。它不会自动判断新 TTL 是否更长，因此在多处代码都负责续期时，后写入的较长值可能把先前设置的短窗口覆盖掉。

LT 把比较条件交给 Redis：只有新的过期时间早于当前过期时间，命令才会写入；如果新值更长或相同，则保持原来的过期时间。这里比较的是键最终的过期时刻，不是简单比较客户端发送命令的先后。对一个还没有 TTL 的非易失键，Redis 会把当前过期时间视为无限大，因此第一次使用 LT 仍可以建立过期时间。

用 EXPIRE LT 只允许更短的 TTL 写入

最小写法就是在普通命令末尾加上 LT。下面的命令先建立一个较长窗口，再尝试写入更短和更长的窗口。命令块只展示发送给 Redis 的输入，返回值在正文中单独解释。

# 创建示例键，并先设置一个 300 秒过期时间
redis-cli SET cache:user:42 "v1"
redis-cli EXPIRE cache:user:42 300

# 新 TTL 为 60 秒，更短，所以允许更新
redis-cli EXPIRE cache:user:42 60 LT

# 新 TTL 为 600 秒，更长，所以不会覆盖现有的短 TTL
redis-cli EXPIRE cache:user:42 600 LT

# 用 TTL 观察剩余秒数，实际值会随时间递减
redis-cli TTL cache:user:42

第一次带 LT 的命令满足条件时返回整数 1；第二次因为新过期时间更晚，返回 0。返回 0 不代表 Redis 出错，而是说明这次条件写入被跳过，原有 TTL 仍由 Redis 继续维护。

这个写法适合把“最迟多久必须失效”作为保护规则，例如短时缓存、临时授权窗口、失败重试冷却时间和风控观察窗口。它不适合表达“每次访问都延长有效期”的滑动窗口，那类需求仍然应该使用普通 EXPIRE，或者明确计算新的续期策略。

通过返回值和 TTL 判断到底发生了什么

EXPIRE 的整数返回值只有两个关键含义：1 表示过期时间已设置，0 表示没有设置。后者可能是键不存在，也可能是 LT 条件不满足，排查时要结合 TTL 或 PTTL 观察。

# 查看秒级 TTL：正数表示剩余秒数，-1 表示没有过期，-2 表示键不存在
redis-cli TTL cache:user:42

# 需要毫秒级窗口时使用 PTTL
redis-cli PTTL cache:user:42

# 查看一个明确不存在的键，便于区分 -2 与 -1
redis-cli TTL cache:user:missing

LT、NX、XX 和 PEXPIRE 应该怎么选

Redis 的条件选项是互斥的，不能把它们拼成一串复杂规则。选择时先说清楚你要保护的业务约束：

• NX：只有键当前没有过期时间时才设置，适合“只在第一次建立 TTL”。
• XX：只有键已经有过期时间时才设置，适合拒绝给持久键意外加上 TTL。
• GT：只有新的过期时间更晚时才更新，适合滑动窗口或延长有效期。
• LT：只有新的过期时间更早时才更新，适合缩短风险窗口或防止缓存被延长。

如果业务以毫秒为单位，使用语义对应的 PEXPIRE key milliseconds LT。它与 EXPIRE 的条件规则相同，只是 TTL 的输入精度变为毫秒。不要为了显示更精细就把秒级业务随意改成毫秒级，关键是让生产端、读取端和排障指标使用同一单位。

# 毫秒级短 TTL：只有 1500 毫秒早于当前过期时间时才更新
redis-cli PEXPIRE cache:user:42 1500 LT

# PTTL 用毫秒读取剩余时间，返回值同样会随时间递减
redis-cli PTTL cache:user:42

并发刷新时为什么应该让 Redis 做条件判断

一个容易出现的错误是先用 TTL 读出剩余时间，再在应用代码里比较，最后决定是否执行普通 EXPIRE。两个请求之间可能已经有第三个请求改变了过期时间，客户端看到的判断依据因此过时。

直接发送 EXPIRE key seconds LT，比较和写入都在 Redis 命令内部完成。多个刷新请求可以竞争同一个键，但较长的新值不会覆盖较短的现有值。应用只需要根据返回的 1 或 0 记录“已缩短”或“保持原值”，不必把一次读改写流程拆到客户端。

如果更新 TTL 还必须和写入值、删除标记或其他命令绑定，就需要进一步考虑事务或 Lua 脚本，把整组业务操作放进同一个 Redis 端原子边界。只涉及“是否允许这次过期时间覆盖旧值”时，LT 已经提供了足够明确的单命令条件。

几个容易误判的边界

第一，LT 比较的是绝对过期时刻。因为 TTL 会在时间流逝中减少，两个请求即使发送了相同的秒数，最终过期时刻也可能不同；排障时不要只拿客户端参数做静态比较。

第二，键不存在时，EXPIRE 返回 0，不会自动创建一个空键。应用若依赖“写值并设置 TTL”这一整体动作，应选择合适的写入命令或事务边界，不能把 EXPIRE 当成建键命令。

第三，修改键值的命令可能影响过期状态。Redis 官方文档说明，覆盖值的命令可能清除原过期时间，而只改变容器内容的部分操作通常保留 TTL。若业务对过期窗口敏感，写值与设置 TTL 应当放在同一条明确的写入路径中，不要把过期规则散落在多个调用方。

常见问题

EXPIRE LT 返回 0，是不是 Redis 版本不支持？

NX、XX、GT 和 LT 是 Redis 7.0.0 加入的 EXPIRE 条件选项。若服务端低于该版本，先按部署版本确认命令能力；在支持 LT 的版本中，返回 0 更常见的原因是条件未满足或键不存在。

LT 能不能和 NX 一起使用？

不能把互斥选项一起使用。没有 TTL 的键在 LT 语义下被当作拥有无限过期时间，因此“只接受更短 TTL”本身已经可以覆盖首次设置的场景；如果你要表达“只有无 TTL 时才设置”，选 NX。

如何只延长 TTL，不允许缩短？

使用 GT。它与 LT 的方向相反：只有新的过期时间晚于当前过期时间才更新。选择 GT 还是 LT，取决于业务是在保护最长存活窗口，还是保护最迟失效窗口。

需要先 TTL 再 EXPIRE 才安全吗？

只为决定“新 TTL 是否更短”时不需要。让 Redis 直接执行带 LT 的 EXPIRE 可以减少一次网络往返，并把比较和写入放在同一条命令的服务端边界内。