Redis SET NX EX 与 KEEPTTL 的过期策略组合

我在做缓存键迁移时，曾经把“只在键不存在时写入”和“不要改变原来的过期时间”当成同一类条件，结果新值写进去了，TTL 却被意外刷新。Redis 的 SET 其实把这两件事分开：NX 控制是否允许写入，EX 给成功写入设置新的秒级 TTL，KEEPTTL 则保留已有 TTL。

最实用的判断顺序是先问“键已不已存在”，再问“这次要不要设置新的过期时间”。EX 与 KEEPTTL 是两种不同的过期策略，不能同时作为一条命令的过期参数。

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

先把三个参数分工拆开

SET key value NX 的意思是键不存在时才写入；键已经存在时返回空结果，原值不变。EX seconds 是成功写入后设置一个新的秒级 TTL。KEEPTTL 不提供新的秒数，而是要求成功覆盖值时保留键已有的 TTL。

# NX 只负责写入条件，不负责决定 TTL
redis-cli SET cache:user:42 "v1" NX

# 首次创建时设置 300 秒的新 TTL
redis-cli SET cache:user:42 "v1" NX EX 300

# 已有键更新值，但保留原来的 TTL
redis-cli SET cache:user:42 "v2" KEEPTTL

因此，NX 和 EX 可以一起表达“只创建一次并设置初始过期时间”；KEEPTTL 更适合已有键的值迁移。它们解决的是不同维度：一个是写入门槛，一个是过期属性。

按迁移场景选择命令

把迁移任务拆成三个常见场景，命令就不容易混淆。

如果需求是“只有不存在时才写入”，就保留 NX；如果需求是“写入成功就重新开始倒计时”，才加 EX。如果是热修复缓存内容但不希望它因为修复动作延长寿命，则用 KEEPTTL，不要把旧 TTL 读出来再拼到下一条命令里。

用返回值和 TTL 边界固定判断

SET 没有因为条件不满足而写入时，应用端要把空返回当成“本次未更新”，不能当作成功。迁移前后还应把键状态分开看：键不存在时没有旧 TTL，NX EX 成功后才会产生新 TTL；键存在但没有 TTL 时，KEEPTTL 也没有可保留的倒计时。

# 清理演示键，避免旧状态影响判断
redis-cli DEL cache:user:42

# 第一次允许创建，并设置 120 秒 TTL；返回 OK 才代表写入成功
redis-cli SET cache:user:42 "v1" NX EX 120
redis-cli TTL cache:user:42

# 键已存在时 NX 会拒绝这次写入；不要把空返回当成成功
redis-cli SET cache:user:42 "v2" NX EX 120

# 覆盖值但保留剩余 TTL，KEEPTTL 不会把计时重置为 120 秒
redis-cli SET cache:user:42 "v2" KEEPTTL
redis-cli TTL cache:user:42

生产代码还要明确处理 TTL 为负数的两种常见含义：TTL 返回 -1 表示键存在但没有过期时间，-2 表示键不存在。它们是排查状态的信号，不应被简单转换成“永不过期”或“马上重试”。

在客户端封装中固定参数含义

当业务层到处拼接 NX、EX 和 KEEPTTL，迁移策略很容易被一次普通更新改掉。可以用有名字的函数把三类意图固定下来。下面是 Go 客户端的伪业务封装，具体参数类型按项目使用的 Redis 客户端调整。

// CachePolicy 将业务意图映射为一条明确的 SET 策略。
type CachePolicy int

const (
    // CreateOnce 只允许首次创建，并设置初始 TTL。
    CreateOnce CachePolicy = iota
    // RefreshLifetime 允许覆盖值，并重新设置 TTL。
    RefreshLifetime
    // ReplaceKeepTTL 允许覆盖值，但不延长已有生命周期。
    ReplaceKeepTTL
)

// setArgs 返回给客户端库的 SET 选项；调用方应检查 nil 返回表示未写入。
func setArgs(policy CachePolicy, ttl time.Duration) []interface{} {
    switch policy {
    case CreateOnce:
        // NX 与 EX 组合，适合首次建立缓存。
        return []interface{}{"NX", "EX", int(ttl.Seconds())}
    case RefreshLifetime:
        // EX 会让成功写入重新开始倒计时。
        return []interface{}{"EX", int(ttl.Seconds())}
    case ReplaceKeepTTL:
        // KEEPTTL 不接受新的秒数，保留 Redis 中已有的 TTL。
        return []interface{}{"KEEPTTL"}
    default:
        // 未知策略不要静默退化成普通 SET。
        return nil
    }
}

如果客户端库把选项拆成结构体，就保持同样的语义分层：创建策略、刷新生命周期策略、保留生命周期策略分别命名。测试至少覆盖首次写入返回成功、已有键被 NX 拒绝、EX 重设 TTL、KEEPTTL 保留 TTL 四个断言。

常见问题

可以同时写 EX 和 KEEPTTL 吗？

不能把它们当成两个叠加的过期参数。EX 代表设置新的秒数，KEEPTTL 代表保留已有过期时间；二者是互斥的策略选择。

NX 失败时会不会把 TTL 也刷新？

不会。键已存在时，NX 条件不满足，整次 SET 不写入，原值和原 TTL 都应保持不变。

没有旧 TTL 时使用 KEEPTTL 会生成一个 TTL 吗？

不会。它的语义是保留已有 TTL；如果键没有过期时间，就没有新的倒计时可供保留。需要设置新 TTL 时应明确使用 EX 或 PX。

总结

记住三个判断就够了：NX 决定“允许不允许写”，EX 决定“成功后设置多少秒”，KEEPTTL 决定“覆盖时是否沿用已有倒计时”。首次建立缓存常用 NX EX，强制刷新生命周期用 EX，只换值不续期用 KEEPTTL；最后用返回值和 TTL 的边界把迁移策略固定下来。