登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  数据库 >  Redis

Redis EXPIRE 的 NX、XX、GT、LT 怎么选:缓存续期别把 TTL 改乱

来源:17golang原创

时间:2026-07-16 15:58:33 250浏览 收藏

订单详情缓存本来设置为10分钟过期,后台刷新任务每隔一会儿就补一次 EXPIRE。看上去只是续期,实际很容易把短期缓存越拉越长,或者给原本不该过期的key加上TTL。Redis 7.0之后,EXPIRE 多了 NXXXGTLT 四个条件参数,续不续、只延长还是只缩短,可以直接写在命令上。

你可以直接按业务场景匹配参数:首次初始化TTL选NX、只操作已有过期时间的临时缓存选XX、仅允许延长有效期选GT、仅允许缩短有效期选LT,操作前后核对TTL返回值,就能避免续期逻辑把全局缓存的过期时间改乱。

实践要点

  • NX 用于“只在第一次设置TTL”,不会覆盖已有的过期时间。
  • XX 用于“只改已有TTL”,避免给永久key意外加上过期时间。
  • GT 只允许延长,LT 只允许缩短;它们适合把缓存窗口限制在单一方向。
  • 先看 TTL-1 是存在但无TTL,-2 是key不存在;条件命令返回 0 时不要当成网络故障。

旧写法的问题不在命令,而在“总是覆盖”

早期常见的写法是:只要缓存被访问,就再次调用一次 EXPIRE cache:order:981 600。这个命令本身没有错,但它不会区分key原来有没有TTL,也不会比较新旧剩余时间。一个“每次访问都续十分钟”的动作,可能让热点key长时间不离开内存;另一类任务则可能把已经剩30分钟的有效窗口误缩成10分钟。

先用最小命令看清现状。返回值是后续判断的依据,不要只盯着命令是否发出:

SET cache:order:981 "ready"
TTL cache:order:981
# (integer) -1

EXPIRE cache:order:981 600
# (integer) 1

TTL cache:order:981
# 大约 600

这里的 -1 表示key还在,但没有过期时间。若你不希望刷新任务碰到永久key,就不能直接使用无条件 EXPIRE;要把“是否已有TTL”变成命令的一部分。

Redis 缓存 key 经过 TTL 检查后按 NX、XX、GT、LT 条件选择是否更新过期时间的关系图

四个条件参数分别解决什么边界

Redis官方文档把这四个参数定义为互斥选项,一次只选一个。它们不是四种语法糖,而是四个不同的时间语义:

参数允许设置TTL的条件适合的场景容易误解的点
NXkey当前没有TTL只补首次过期时间已有TTL时返回0,不会重新计时
XXkey当前已有TTL只刷新临时缓存永久key不会被改成临时key
GT新TTL大于当前TTL只允许延长有效窗口无TTL的key按无限TTL看待,有限秒数不会通过
LT新TTL小于当前TTL紧急收紧缓存窗口无TTL的key按无限TTL看待,有限秒数可通过

例如会话缓存刚写入时要补一次默认TTL,可以选 NX;清理任务只想缩短异常订单的缓存窗口,可以选 LT。这里别急着把 GT 当成“续期万能开关”:它只比较剩余时间,不知道业务上的绝对截止时间。若缓存不能跨过某个固定时刻,应由应用先算出正确秒数,再把条件命令当作最后一道保护。

EXPIRE cache:order:981 600 NX
# key 原本无 TTL 时返回 1;已有 TTL 时返回 0

EXPIRE cache:order:981 900 GT
# 仅当当前剩余时间小于 900 秒时返回 1

EXPIRE cache:order:981 120 LT
# 仅当当前剩余时间大于 120 秒时返回 1

命令返回 1 说明本次确实更新了过期时间;返回 0 则说明key不存在或条件不满足。把这个结果记到业务日志或指标中,才能分辨“没有缓存”与“条件主动拒绝更新”。

Redis 7.0的条件语义,替代了哪些应用层补丁

在这些参数出现前,应用通常先读 TTL,再决定是否调用 EXPIRE。两条命令之间可能被其他请求改变TTL;即便没有并发问题,代码也常把 -1-2 和正常秒数混在一段分支里。条件参数把一部分判断放回Redis,减少了“先看再改”的往返和竞态窗口。

这不代表 TTL 可以完全删掉。它仍然适合监控、排障和测试中确认状态。一个紧凑的核对流程是:先读取一次TTL认识现状,发出带条件的EXPIRE,再读取TTL确认结果是否符合预期。

TTL cache:order:981
EXPIRE cache:order:981 900 GT
TTL cache:order:981

注意秒数不能传0或负数。官方文档说明,EXPIRE 的非正超时会删除key,而不是让key进入普通的过期流程。把“清缓存”写成显式删除动作通常更容易审计;把这个边界混进续期参数,很容易让故障处理变成数据丢失。

Redis TTL 从无过期、短 TTL 和长 TTL 三种状态经过条件 EXPIRE 后的前后变化关系图

兼容和上线时,先做四个小检查

NX、XX、GT、LT从Redis 7.0开始提供。混合版本、旧测试环境或客户端封装较旧时,先确认服务端版本和客户端是否能发出该参数。客户端没有对应的高级方法并不代表不能使用,只是不要猜测它的参数名或返回类型。

  1. 在测试库分别准备无TTL、短TTL、长TTL和不存在的key。
  2. 对每种key各跑一次目标条件,记录命令返回的1或0。
  3. 再读TTL,确认时间只朝预期方向变化。
  4. 检查业务日志是否把“条件未满足”误报成刷新失败。

缓存续期真正要保护的是业务窗口,不是某一条命令。把条件写在 EXPIRE 上,再用TTL和返回值做核对,能让“谁可以改变过期时间”变得可见,也更容易在后续规则变化时回看。

相关问题

NX、XX、GT、LT能一起传吗?

不能。Redis将它们定义为互斥条件,一次EXPIRE只应选择一个时间语义。

TTL返回0代表什么?

TTL返回的是剩余秒数,接近过期时可能显示0。命令返回0则是另一件事,表示EXPIRE没有设置TTL,可能是key不存在或条件不满足。

为什么GT对没有TTL的key不生效?

在GT/LT的比较规则里,没有TTL的key被当作无限TTL。有限秒数不会比无限大,所以GT不会通过;相反,LT可以把它收紧为有限TTL。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>