Redis SET 怎样同时设置 NX 与过期时间

如果业务需要“键不存在才写入，而且写入后必须自动过期”，不要先执行 SETNX，再单独执行 EXPIRE。这两步之间一旦发生进程退出或连接中断，就可能留下没有 TTL 的键。更稳妥的写法是把条件和过期选项放到同一条 SET 命令里：

# 只有 lock:order:1001 不存在时写入，并设置 30 秒过期
redis-cli SET lock:order:1001 worker-7 NX EX 30

# 如果需要毫秒级 TTL，把 EX 换成 PX
redis-cli SET cache:profile:42 v1 NX PX 1500

官方命令说明页：https://redis.io/docs/latest/commands/set/。上面的命令返回 OK 时表示本次写入和过期设置都接受；返回空结果时表示 NX 条件不满足，原有值不会被覆盖。

先看清这个组合解决了什么问题

NX 的含义是“仅当键不存在时设置”，EX 以秒设置相对过期时间，PX 以毫秒设置相对过期时间。三者组合后，条件判断和 TTL 绑定在同一次 SET 操作中，调用方不需要在中间窗口里补一条 EXPIRE。

这不是把 Redis 变成了永久锁。它适合做短时间的互斥标记、重复提交抑制、临时幂等占位或缓存初始化竞争；锁值的有效期仍然需要小于业务可能持续的最长时间，超过有效期后另一个持有者可能获得同一把逻辑锁。

用返回值判断谁拿到了写入权

抢占类逻辑不要只看客户端是否没有抛异常，而要判断命令返回值。第一次执行通常得到 OK；键已经存在时，NX 让命令放弃写入，客户端一般得到空值或对应语言的 nil。

package main

import (
	"context"
	"fmt"
	"time"

	"github.com/redis/go-redis/v9"
)

func acquire(ctx context.Context, rdb *redis.Client, key, token string) (bool, error) {
	// NX 负责“只在不存在时写入”，EX 让占位不会永久残留。
	result, err := rdb.SetArgs(ctx, key, token, redis.SetArgs{
		Mode: "NX",
		TTL:  30 * time.Second,
	}).Result()
	if err != nil {
		// 网络错误不能当成“没有抢到”，应交给上层重试或降级。
		return false, err
	}
	// go-redis 在条件不满足时返回 redis.Nil；成功时返回 OK。
	return result == "OK", nil
}

func main() {
	_ = fmt.Println
}

上面的客户端示例强调判断方式，但实际项目中应让客户端的参数映射与当前版本文档保持一致；如果使用直接命令接口，等价语义就是 SET key token NX EX 30。网络错误、超时和条件不满足是三种不同结果，不能把它们都当成“锁已被占用”。

如果只需要命令行或脚本调用，可以把结果分支写得更直白：

# 成功分支得到 OK，空输出表示键已存在
result="$(redis-cli --raw SET lock:order:1001 worker-7 NX EX 30)"
if [ "$result" = "OK" ]; then
  # 只有这里才进入临界区
  echo "acquired"
else
  # 条件未满足时不要覆盖原持有者的值
  echo "busy"
fi

EX、PX、EXAT 和 PXAT 怎么选

相对过期优先选 EX 或 PX：调用时从当前时刻开始计算，适合“占位 30 秒”“缓存 1500 毫秒”这类场景。EXAT 和 PXAT 则传入 Unix 时间点，适合多个调用方共同遵守一个明确截止时刻，但要承担时钟来源和时间单位管理责任。

# 相对 TTL：从命令接受时刻起计算 30 秒
redis-cli SET lock:job:9 worker-7 NX EX 30

# 绝对截止时间：参数是 Unix 时间戳，不是“还剩多少秒”
redis-cli SET lock:job:9 worker-7 NX EXAT 1792416610

读取 TTL 时，TTL 返回秒，PTTL 返回毫秒；负数还可能代表键不存在或没有设置过期时间。排查时不要仅凭一次 TTL 读数判断业务是否成功，因为读取本身也会消耗时间。

锁值、释放和续期不能省略

把随机 token 作为值写入，比固定写入 locked 更安全。释放时不能无条件执行 DEL：当前请求可能已经超时，键又被新的持有者重新设置，此时旧请求再删除就会误删新锁。释放动作应使用“比较值再删除”的原子脚本或受支持的服务端条件删除能力。

续期也要先判断 token 仍属于自己，再更新 TTL。单独调用 EXPIRE key 30 可能延长了别人的锁；单独调用 GET 再 EXPIRE 又会引入竞态。文章标题只覆盖 SET 的原子占位，因此这里的边界是：SET NX EX 能安全建立一个带租期的标记，但不能自动完成锁的身份校验、续期和释放。

可以按下面的清单做选择：

• 只需“首次写入并自动回收”：SET key value NX EX seconds。
• 短窗口需要毫秒精度：使用 PX，并统一客户端和服务端的单位。
• 需要统一截止点：使用 EXAT 或 PXAT，同时明确时间戳来源。
• 把它当分布式锁：使用唯一 token，并设计校验 token 的释放与续期逻辑。
• 不能接受租期失效后的并发风险：不要只依赖一条 SET，改用经过评估的锁服务或更完整的协调方案。

相关问题

SETNX 和 SET NX 有什么区别？ 官方文档把 SET NX 作为更灵活的写法，能同时组合 EX、PX 等过期选项；单独使用 SETNX 不能在同一条命令里表达租期。

SET NX EX 返回空值怎么办？ 先按“条件不满足”处理，不要覆盖键值；如果业务允许等待，再设置带退避的重试上限，并区分网络错误。

为什么设置了 EX 还会出现永久键？ 可能是实际执行了分步 SETNX/EXPIRE、参数顺序或单位写错，或者后续代码使用不带 TTL 的 SET 覆盖了同一个键。用 TTL key 和调用日志定位写入路径。