Redis GETEX 怎样读取并同时调整过期时间

我在做“读到缓存就延长可用时间”的场景时，最初把 GET 和 EXPIRE 分成两次调用。这样写不难，但客户端要处理两次往返，两个命令之间也会留下一个不必要的时间窗口。Redis 的 GETEX 更直接：它返回字符串值，同时按参数设置或移除过期时间。

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

需要“读取字符串并调整 TTL”时，优先使用 GETEX key EX seconds 或 GETEX key PX milliseconds。如果只写 GETEX key，它只读取，不会主动添加新的过期时间。

先区分 GETEX 与 GET

GETEX 从 Redis Open Source 6.2.0 开始提供，时间复杂度是 O(1)，但它不是纯读命令，而是带有 @write 分类的字符串命令。这个区别很重要：在 ACL、只读副本或命令审计环境中，不能把它当作普通 GET 处理。

它的最小形式是 GETEX key。key 存在时返回字符串值；没有过期参数时，原有 TTL 不会被重新设置。加上 EX 60 后，返回值仍然是字符串，但生命周期会被改成约 60 秒。对我来说，这就是它替代“GET 后再 EXPIRE”的主要价值：读值和 TTL 变更由一条 Redis 命令表达。

# 写入一个字符串，作为后续 GETEX 的读取对象
redis-cli SET session:42 "user-data"

# 读取值，同时把相对过期时间设置为 60 秒
redis-cli GETEX session:42 EX 60

# 查看剩余生命周期；实际显示会随读取时间减少
redis-cli TTL session:42

如果业务只想读取，不想改变生命周期，直接使用 GET 更容易表达意图；如果读取动作本身就是一次续期或生命周期调整，GETEX 会更清楚。

按业务选择 EX、PX、EXAT、PXAT 或 PERSIST

GETEX 的过期参数是互斥的，一次只选择一种。EX 使用秒，PX 使用毫秒；EXAT 和 PXAT 则把过期点写成 Unix 时间戳。若要保留值但去掉 TTL，用 PERSIST。

# 用毫秒设置相对过期时间，适合短窗口控制
redis-cli GETEX session:42 PX 1500

# 用 Unix 秒指定统一截止时刻；时间戳要由业务侧先算好
redis-cli GETEX session:42 EXAT 1792291200

# 读取值并移除 TTL，使 key 不再按过期时间自动删除
redis-cli GETEX session:42 PERSIST

我的经验是：相对窗口优先用 EX 或 PX，只有业务真的围绕“某个固定时刻”协作时才用 EXAT 或 PXAT。这样不容易把“延长 60 秒”和“保留到某个时间点”混成两种不同的策略。

几个容易被忽略的边界

第一，key 不存在时，GETEX 返回空值，不会凭空创建 key；调用方应把空值当成缓存未命中处理。第二，GETEX 面向 Redis 字符串值，key 的类型不符合要求时会收到类型错误，不要拿它读取 Hash、List 等其他数据结构。第三，PERSIST 的语义是移除已有 TTL，而不是把 TTL 改成一个很大的数字。

还有一个部署层面的提醒：官方命令文档把 GETEX 标为写命令。因此，如果应用连接的是只读副本，或者 ACL 只允许读命令，调用可能被拒绝。客户端库的参数名虽然可能不同，但都应映射到同一组互斥选项；先确认客户端支持 GETEX，再决定是否用它替代两次调用。

常见问题

GETEX key 不带参数会把 TTL 清掉吗？

不会。它只返回值，不会主动新增或移除过期时间；要移除 TTL，明确使用 PERSIST。

EX 和 EXAT 应该怎么选？

从当前时刻计算生命周期，用 EX；多个服务必须对齐同一个截止时刻，用 EXAT。PX 和 PXAT 只是把单位提高到毫秒。

为什么 GETEX 在只读连接上失败？

因为它会改变 TTL，Redis 将其分类为写命令。检查连接目标和 ACL 权限，纯读取场景则使用 GET。

总结

GETEX 的核心不是“更短的 GET 写法”，而是把返回字符串与生命周期调整放在一次命令语义里。先判断你要的是相对时间、绝对时间还是移除 TTL，再选择 EX、PX、EXAT、PXAT 或 PERSIST；最后记住它属于写命令，这一点会直接影响权限和连接路由。