Redis SET 的 GET 与 KEEPTTL 怎么一起验收：旧值返回、续期与回滚边界

缓存里的配置值需要热更新时，最容易漏掉的不是新值，而是旧值和过期时间。比如 feature:checkout 原本还有 120 秒 TTL，应用用一条普通 SET 更新后，值变了，TTL 却可能变成永久；如果再额外执行一次 GET，并发窗口也会变大。Redis 的 SET 可以把“写入、返回旧值、保留 TTL”放进一次命令，关键是验收返回值和 TTL，而不是只看一个 OK。

把GET参数和KEEPTTL参数搭配在同一条SET命令里，就能在原子操作里拿到更新前的旧值，同时完全保留键原本的剩余过期时间，验收时只要覆盖旧值比对、TTL区间校验、条件写入边界校验三项，就能避开绝大多数隐蔽的并发和时间逻辑漏洞。

SET 组合先看返回值：写入前后的值必须分开核对

先准备一个有过期时间的字符串键。下面的命令把当前值设成 v1，有效期 120 秒：

SET feature:checkout v1 EX 120
TTL feature:checkout
GET feature:checkout

现在要把配置升级为 v2，同时知道原来是什么版本。不要写成“先 GET、再 SET”的两条业务命令，而是直接组合：

SET feature:checkout v2 GET KEEPTTL
TTL feature:checkout
GET feature:checkout

第一次响应应是旧值 v1，而不是 OK；随后读到的当前值是 v2，TTL 仍应接近原来的剩余时间。TTL 会自然减少，所以验收时检查范围比检查固定整数更可靠。

NX、XX 和 GET 怎么搭配：条件失败也要有明确分支

GET 只说明“如果发生写入，返回旧字符串值”。它不会取消 NX 或 XX 的条件判断。可以先把规则压缩成这张表：

例如只允许覆盖已有配置：

SET feature:checkout v3 XX GET KEEPTTL
GET feature:checkout
TTL feature:checkout

当键不存在时，条件不满足，返回空值并且键不会被创建。业务层应把它当成“目标不存在”，而不是把空值当作一次成功更新。若客户端使用 RESP3 或语言 SDK，空响应的具体类型可能显示为 null、None 或 nil，判断语义即可。

KEEPTTL 的验收边界：保留旧 TTL 不等于自动续期

KEEPTTL 的动作是保留已有过期时间，不是把倒计时重置为某个新值。下面这个实验能看出差别：

SET feature:checkout v1 EX 20
TTL feature:checkout
SET feature:checkout v2 KEEPTTL
TTL feature:checkout
SET feature:checkout v3 EX 120
TTL feature:checkout

第二次更新后，TTL 仍然会继续减少；第三次显式给出 EX 120，才会把过期策略改成新的 120 秒。把“刷新配置”误写成 KEEPTTL，会让热点键在旧倒计时结束时突然消失。

把更新封装成可回滚的检查清单

线上热更新建议把命令结果记录成三元组：old_value、current_value、ttl_after。最小检查可以按下面顺序走：

1. 先确认键类型是 string，避免对 Hash、List 等键误用 SET。
2. 根据业务决定 NX 还是 XX，不要把条件交给异常重试猜测。
3. 已有 TTL 且只改值时使用 KEEPTTL；需要续期时显式使用 EX 或 PX。
4. 把 GET 返回的旧值写入审计日志，但避免记录敏感配置正文。
5. 更新后立刻读取或通过客户端返回值确认当前版本，并检查 TTL 是否落在预期区间。

如果更新失败，回滚动作也应有明确条件。例如只有当当前值仍是本次写入的 v2 时，才允许恢复 v1；否则说明已有别的更新，不能用旧值覆盖新值。Redis 版本较新时，可以进一步评估条件写入能力，但不要把本文的 NX/XX 当成版本比较。

常见问题

SET GET KEEPTTL 返回的为什么不是 OK？

因为 GET 要求返回写入前的字符串值。键原来不存在时通常得到空响应；这与写入是否成功要结合条件和后续读值判断。

KEEPTTL 能给新键设置默认过期时间吗？

不能。新键没有可保留的 TTL，首次创建应使用 EX、PX、EXAT 或 PXAT 明确设置过期策略。

SET XX GET KEEPTTL 条件失败会不会覆盖旧值？

不会。键不存在时 XX 条件不满足，命令不写入；应用应把空响应识别为未更新。

想续期时还能保留 KEEPTTL 吗？

不要把两种意图混在一起。保留旧倒计时用 KEEPTTL，重置或延长倒计时就显式给出新的 EX 或 PX。

Redis SET 的组合参数并不复杂，难点在于把返回值、条件结果和 TTL 作为一次更新的完整证据。只要把三项都写进验收记录，配置热更新就不容易出现“值对了、过期时间错了”的隐蔽问题。