当前位置：首页 > 文章列表 > 数据库 > Redis > Redis EXPIRE 的 GT 和 LT 条件怎么使用

Redis EXPIRE 的 GT 和 LT 条件怎么使用

来源：17golang原创 2026-09-27 07:09:14 0浏览收藏

缓存续期时，普通 EXPIRE key seconds 会直接改写过期时间，调用方如果算错一次，就可能把一个原本还剩 300 秒的 key 改成 30 秒。Redis 7.0.0 起，可以用 GT 和 LT 把这个动作变成有条件的更新：GT 只接受更长的新 TTL，LT 只接受更短的新 TTL，条件不满足时返回 0，原来的过期时间不变。

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

要点速览

续期、延长窗口用 GT；主动收紧窗口用 LT。
返回 1 代表过期时间已设置，返回 0 代表 key 不存在或条件没有命中。
TTL -1 是存在但没有过期时间，TTL -2 是 key 不存在，两者不要混为一谈。

一、GT、LT 和普通 EXPIRE 的区别

先看命令形态：

# 给 key 设置 120 秒过期；没有条件时会直接覆盖原 TTL
redis-cli EXPIRE cache:user:42 120

# 只有新 TTL 大于当前 TTL 时才更新，适合续期
redis-cli EXPIRE cache:user:42 120 GT

# 只有新 TTL 小于当前 TTL 时才更新，适合收紧过期窗口
redis-cli EXPIRE cache:user:42 30 LT

写法	比较规则	适合场景	条件不满足
EXPIRE key n	直接设置	初始化或明确覆盖	不适用
EXPIRE key n GT	n 大于当前 TTL	续期、延长保护窗口	返回 0
EXPIRE key n LT	n 小于当前 TTL	撤销、降级、收紧窗口	返回 0

这里比较的是 key 的过期时间，不是缓存值本身。GT 和 LT 互斥，不能在同一次 EXPIRE 中同时使用；命令复杂度为 O(1)。

Redis EXPIRE 比较当前 TTL 与新 TTL 后由 GT 或 LT 返回 1 或 0 的关系说明图 — 图1：Redis EXPIRE 的 GT/LT 条件关系说明图，不是运行截图。

二、用 TTL 先观察，再用 GT 只延长有效期

续期代码常见的风险是“每次刷新都覆盖”。例如一个接口希望把登录态至少保持 10 分钟，但某个慢请求只计算出了 20 秒，普通 EXPIRE 会把窗口缩短。可以先读 TTL 做诊断，再使用 GT 让 Redis 自己完成原子条件判断。

# 先创建一个演示 key，并设置较短的初始 TTL
redis-cli SET session:42 active
redis-cli EXPIRE session:42 60

# 当前 TTL 可能接近 60；120 GT 会命中，因为新值更长
redis-cli TTL session:42
redis-cli EXPIRE session:42 120 GT
redis-cli TTL session:42

# 30 GT 不会命中，原 TTL 不会被缩短
redis-cli EXPIRE session:42 30 GT

TTL 只适合观察，不能替代条件写入：客户端先读再在代码里比较，期间可能被另一个请求修改。真正的保护应交给带 GT 的 EXPIRE；应用侧只需要根据返回值决定是否记录续期结果。

三、用 LT 只缩短 TTL，并识别条件未满足

LT 适合“最长不能超过某个窗口”的场景。比如风控标记原本还有 900 秒，但策略升级后要求 120 秒内失效，此时可以执行 EXPIRE risk:user:42 120 LT。如果当前只剩 60 秒，命令返回 0，避免把已经更短的时间重新延长。

# 风控策略只允许把剩余时间收紧到 120 秒以内
redis-cli EXPIRE risk:user:42 120 LT

# 返回 1：新的过期时间已设置；返回 0：key 不存在或当前 TTL 不大于新值
# 之后再读一次，确认条件写入后的 TTL 仍在预期范围
redis-cli TTL risk:user:42

要注意，返回 0 不是 Redis 报错。它表示这次条件更新没有发生，业务可以按幂等成功处理，也可以把它记录为“无需收紧”。只有连接失败、参数错误等异常，才应该进入重试或错误告警。

四、处理无过期、键不存在和边界值

写条件过期前，至少要能解释下面四类状态：

TTL key = -2：key 不存在，任何 EXPIRE 都不会成功。
TTL key = -1：key 存在但没有过期时间。对非 volatile key，GT 会把它视为无限 TTL，所以不会用有限秒数覆盖；LT 则可以设置有限 TTL。
新 TTL 与当前 TTL 相等：既不满足 GT，也不满足 LT，返回 0。
新 TTL 小于等于 0：不是普通等待过期，而是立即删除 key，应用不要把它当作成功续期。

Redis TTL -2、TTL -1、相等 TTL 和非正秒数对应 EXPIRE GT LT 边界结果的结构说明图 — 图2：TTL 状态与 EXPIRE 边界结果的静态关系说明图，不是运行截图。

另外，GT、LT 随 Redis 7.0.0 加入。如果客户端或服务端版本较旧，先确认命令能力，再决定是否回退到业务侧方案；不要把未知参数错误误判成条件未满足。

五、把条件结果接入应用侧检查清单

实际代码可以按“条件选择—判断返回值—必要时复查 TTL”的顺序组织。续期任务默认使用 GT，撤销或降级任务默认使用 LT，并把 seconds 的单位固定成秒，避免把毫秒误传给 EXPIRE。

检查项	建议
首次写入	明确是否需要直接 EXPIRE，或用 SET 的 EX/PX 一起初始化。
续期	优先 `EXPIRE key n GT`，返回 0 时不重试同一个更短值。
收紧	使用 `EXPIRE key n LT`，把 0 当作“已经更短或不存在”处理。
复查	只在需要记录结果时读取 TTL，不用“读 TTL 再普通 EXPIRE”代替条件命令。