Redis SET NX EX 组合怎么避免锁没有过期时间

订单、库存或定时任务需要“同一时间只有一个实例处理”时，Redis 分布式锁最容易留下两个坑：锁创建成功了，却没有 TTL；锁过期后，旧实例又把新实例的锁删掉。解决方式不是把 SETNX 和 EXPIRE 拼成两次请求，而是用一条 SET key value NX EX seconds 命令原子完成创建，再用唯一 token 做释放校验。

抢锁使用 SET ... NX EX，把唯一 token 作为 value；释放时用 Lua 在同一段脚本里比较 token，匹配才 DEL。这样既不会留下没有过期时间的锁，也能避免旧持有者误删新锁。

为什么 SET NX EX 要写在同一条命令里

下面这种写法存在空窗：第一条命令成功后，进程在第二条命令前崩溃，锁键就会一直存在。

# 错误示例：两次请求之间可能发生进程崩溃或网络断开
SETNX lock:order:42 1
EXPIRE lock:order:42 30

Redis 官方 SET 语法允许把条件写入和过期选项放在同一个命令中。NX 只在键不存在时成功，EX 30 则让成功创建的键拥有 30 秒 TTL；已有键会直接返回空结果，不会覆盖持有者。

# 推荐：抢锁、写入 token、设置过期时间属于一次 SET 语义
SET lock:order:42 7f4c2e8a NX EX 30

# 成功返回 OK；竞争失败返回空结果
GET lock:order:42
TTL lock:order:42

锁值为什么必须是每次请求生成的 token

锁值的作用不只是“占位”。它还要回答：现在这个锁是不是我加的？如果所有实例都写入 1，释放方无法区分自己的锁和别人的锁。应在客户端生成足够随机的 token，例如 UUID 或安全随机字节，再把它作为 value。

TTL 不是“任务一定能在 30 秒内完成”的证明。临界区可能因为下游接口、GC 或调度暂停而超过 TTL；如果业务允许续期，就要用同一个 token 重新确认所有权后再续期，不能无条件延长一个已经被别人接管的键。

EX 和 PX 怎么按业务耗时选择

EX 使用秒，适合几十秒级的短任务；PX 使用毫秒，适合需要更细粒度控制的场景。选择时先估计正常耗时，再为抖动留出余量，并让“拿到锁后执行的业务”具备超时和幂等保护。

排查“锁没有过期时间”时，先用 TTL lock:order:42 看秒级剩余时间；返回 -1 表示键存在但没有过期时间，通常意味着旧代码只执行了 SETNX 或后续 EXPIRE 没有成功。返回 -2 表示键已经不存在。毫秒场景使用 PTTL。

释放锁时为什么不能直接 DEL

假设实例甲拿到锁后暂停，30 秒 TTL 到期；实例乙随后拿到同一个 key。此时实例甲恢复，如果直接执行 DEL lock:order:42，删掉的其实是实例乙的新锁。正确做法是读取当前 value，与甲保存的 token 比较，只有相等才删除，而且读取、比较、删除必须保持原子性。

-- 释放锁：只有当前值仍属于本 owner 才删除
if redis.call('get', KEYS[1]) == ARGV[1] then
  return redis.call('del', KEYS[1])
end
return 0

调用时把锁键放在 KEYS[1]，把持有者 token 放在 ARGV[1]。脚本返回 1 表示删除成功，返回 0 表示 token 不匹配或锁已不存在。不要在客户端先 GET，判断后再单独 DEL，因为两次请求之间仍然可能发生过期和重新加锁。

上线前用这份清单复查锁边界

• 抢锁命令是否同时出现 NX 与 EX/PX？
• 锁值是否每次请求唯一，而不是所有实例共用 1、true 或服务名？
• 业务失败、超时和进程崩溃后，是否能依靠 TTL 恢复，而不是等待人工清理？
• 释放和续期是否先校验 token，并将校验与写操作放在 Lua 或等价的原子机制中？
• 拿到锁后重复执行是否安全？分布式锁不能替代数据库唯一约束、幂等键和事务。

相关问题

SET NX EX 返回空值代表什么？

代表 key 已存在，当前请求没有拿到锁。应按退避策略重试或返回“稍后再试”，不要立即覆盖这个键。

为什么 TTL 返回 -1？

key 存在但没有过期时间。重点检查是否使用了旧的 SETNX 流程，或 EXPIRE 是否因为异常、分支提前返回而没有执行。

锁过期前还没做完怎么办？

可以设计带 token 校验的续期，并设置最大租期；同时让业务幂等，防止租约到期后新旧实例短暂重叠。

Redis 锁能保证数据库事务不冲突吗？

不能单独保证。数据库仍需要唯一索引、事务隔离或幂等写入，Redis 锁只是减少同一资源的并发进入。