Redis EXPIRE与持久化更新同时使用的过期语义

Redis 的值更新和过期时间不是同一份数据。排查“缓存更新后一直不失效”时，先看更新命令是替换整个 key，还是只修改已有数据结构；再确认它有没有显式携带新的过期策略。通常，SET 会用新值替换 key 并清掉旧 TTL，HSET 修改哈希字段则会保留 key 的 TTL，SET ... KEEPTTL 可以在替换字符串时保留旧 TTL。

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

最稳的判断方法是把“值是否变化”和“TTL 是否变化”分开验证：更新前后各执行一次 TTL，并根据业务选择保留、重置或删除过期时间，不能只凭写入返回值推断缓存仍会过期。

先把“值更新”和“TTL 更新”分成两条线

Redis 的过期时间挂在 key 上，查询它不会读取值内容。先建立一个带 TTL 的字符串，再分别观察覆盖写和原地改写：

SET cache:user:42 "v1"
# 先给整个 key 设置 60 秒过期时间
EXPIRE cache:user:42 60
TTL cache:user:42
# 这里应得到一个接近 60 的正数，而不是把 TTL 当成值的一部分
SET cache:user:42 "v2"
TTL cache:user:42
# SET 默认替换 key，旧 TTL 会被清除，返回值通常是 -1

上面的结论是语义上的分界：覆盖整个字符串相当于创建新的值对象，旧过期时间不会自动跟随。只要把 TTL 放进回归用例，就能快速发现“更新成功但缓存永不失效”的问题。

替换写入、保留 TTL 和重新计时不是一回事

字符串缓存最容易混淆的有三种写法。SET key value 默认替换值并移除旧 TTL；SET key value KEEPTTL 替换值但保留当前剩余时间；SET key value EX 300 则把新值和新的 300 秒 TTL 一起提交。三者都可能返回成功，但后续生命周期完全不同。

如果业务规则是“只要命中上游就续期”，使用 KEEPTTL 反而不够，还要明确调用 EXPIRE 或使用带过期参数的写入。相反，滑动过期也要设置最大寿命，否则热 key 可能一直留在内存里。

哈希字段更新为什么通常不会刷新 TTL

哈希的字段不是独立 key，过期时间仍属于外层哈希 key。因此 HSET profile:42 name "Lin" 只改字段内容，已有的 profile:42 TTL 通常继续倒计时；HGET、HINCRBY 也不应被误认为续期操作。需要续期时，把策略写出来：

MULTI
# 更新字段，但不让字段更新隐式改变生命周期
HSET profile:42 name "Lin"
# 只有业务确认应续期时，才显式把窗口设为 300 秒
EXPIRE profile:42 300
EXEC

事务只能保证命令按队列执行，不能替代业务判断。若 key 可能被其他客户端删除或改类型，要检查 EXPIRE 的返回结果，并用 TTL 在集成测试中覆盖 key 不存在、没有 TTL 和已接近过期三种状态。

PERSIST、GETEX 和 EXPIRE 条件参数的边界

PERSIST 是显式删除过期时间，不是“把 TTL 暂停”。GETEX 则在读取字符串时可同时设置、保留或移除 TTL，适合需要把读取动作和生命周期策略绑定的场景。Redis 7 之后，EXPIRE 还支持 NX、XX、GT、LT，可限制续期只能发生在特定条件下。

# 只在 key 没有过期时间时设置初始 TTL，避免覆盖已有窗口
EXPIRE cache:user:42 300 NX
# 只把更长的窗口写入，避免并发请求把 TTL 越刷越短
EXPIRE cache:user:42 300 GT
# 读取并把生命周期延长到 120 秒，按业务决定是否采用滑动过期
GETEX cache:user:42 EX 120
# 明确让 key 变成持久 key；返回 1 才表示 TTL 被移除
PERSIST cache:user:42

这些命令表达的是不同的产品决策：初次写入、延长窗口、读取续期和永久保存不能混成一个“更新缓存”的通用函数，否则调用方很难知道 TTL 为什么变化。

上线前用最小清单固定过期语义

回归测试不需要大量数据，关键是把每种写法的前后状态写清楚。至少覆盖以下检查：

• 写入后 TTL 是否为正数，过期后 EXISTS 是否为 0。
• 覆盖写后预期是保留、重置还是得到 -1，不能只断言值等于新内容。
• 哈希字段更新是否仍受外层 key 的倒计时约束。
• 并发续期时，NX/XX/GT/LT 条件是否与最大缓存时长一致。
• 删除、类型错误和 key 已过期时，调用方是否能区分返回值。

常见问题与边界

SET 更新后 TTL 变成 -1 是 Redis 丢数据了吗？

不是值丢失，而是旧过期元数据被覆盖写清除了。若仍需过期，直接使用 SET ... EX 或 SET ... KEEPTTL。

HSET 会不会把哈希的 TTL 重新计算？

通常不会。它修改字段，不等于续期；需要滑动窗口时应显式调用 EXPIRE 或把两条命令放进同一原子边界。

PERSIST 和 KEEPTTL 能一起表达同一个意思吗？

不能。KEEPTTL 保留已有倒计时，PERSIST 删除倒计时，前者用于更新内容，后者用于改变生命周期。

Redis 过期问题的排查顺序可以固定为：先看 key 是否存在，再看 TTL，最后对照写入命令是否替换了 key 或显式改变了生命周期。这样才能把“内容更新成功”和“缓存仍按策略失效”同时验证。