登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  数据库 >  Redis

Redis SET 条件参数怎样实现带过期时间的幂等锁

来源:17golang原创

时间:2026-11-02 07:35:13 278浏览 收藏

我在给重复提交接口加幂等保护时,最容易踩的坑不是“有没有锁”,而是把“判断不存在”“写入锁值”和“设置过期时间”拆成了几次操作。Redis 的 SET 可以用 NX 只在 key 不存在时写入,再用 EX 或 PX 同时设置自动释放时间,正好适合做一把短生命周期的业务锁。

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

最小形式是 SET order:lock:1001 token-abc NX PX 30000:返回 OK 表示当前请求抢到锁,返回空结果表示已有持有者。锁值不要写成固定字符串,而要为每次持有生成唯一 token,否则释放时无法确认“这把锁是不是我加的”。

先把业务对象变成稳定的锁 key

幂等锁的 key 应该对应“同一个业务对象在同一时间只能处理一次”,例如订单号、支付流水号或导入任务号。可以使用 order:lock:{订单号} 这样的命名,不要把整个请求体直接拼进 key。

# 下面是参数示意,不代表已经连接或执行过某个线上 Redis 实例。
key   = order:lock:1001
value = request-7f1c2a

这里的 value 是持有者标识。请求重试时,如果仍在处理同一个订单,应先面对“锁已存在”的结果;不要因为返回空结果就覆盖原 key,否则原来的互斥关系会被破坏。

Redis SET 幂等锁的业务 key、唯一 token、NX 条件和过期参数静态关系说明图
图1:Redis SET 的锁 key、唯一 token、NX 条件与 PX 过期参数关系说明图;这是静态结构图,不是 Redis 控制台截图或运行证据。

用 NX 加过期参数完成一次抢锁

NX 负责“仅当 key 不存在时设置”,EX 以秒为单位设置过期时间,PX 以毫秒为单位。把条件和过期参数放在同一个 SET 中,调用方不需要先 EXISTS 再决定是否写入。

# NX 只允许第一个请求写入,PX 让异常退出后的锁最终自动释放。
redis-cli SET order:lock:1001 request-7f1c2a NX PX 30000

# 读取剩余时间只用于排查锁是否接近过期,不应拿它替代业务判断。
redis-cli PTTL order:lock:1001

第一个请求得到 OK 后才进入实际处理;竞争请求得到 (nil),可以返回“处理中”、进入延迟队列或按业务策略稍后重试。不要把 SETNX 和 EXPIRE 当成更安全的替代方案:它们分成两次命令,进程在中间崩溃时可能留下没有过期时间的锁。

过期时间要覆盖正常处理时长,并预留网络和调度波动,但不能无限拉长。任务可能超过 TTL 时,要设计续期或把任务拆成更小的可重试单元;TTL 到期后,另一请求可能合法地重新获得这把锁。

释放时必须核对 token

直接执行 DEL order:lock:1001 有一个危险窗口:请求 A 的锁已经过期,请求 B 获得了同名新锁,此时 A 才恢复并执行 DEL,就会误删 B 的锁。释放动作必须和 token 比较放在 Redis 内部完成。

-- 只有 key 仍保存当前请求的 token 时才删除,避免误删后来者的锁。
if redis.call('GET', KEYS[1]) == ARGV[1] then
    return redis.call('DEL', KEYS[1])
end
return 0

Redis 官方的分布式锁说明也采用“唯一随机值 + 条件删除”的思路。Redis 8.4 还提供了带条件的 DELEX 形式;如果运行环境较旧,可以使用上面的 Lua 脚本。无论选择哪种写法,核心都是先比较值,再执行删除,而且两步不能由客户端拆开。

Redis 幂等锁从抢锁到过期和按 token 安全释放的对象关系说明图
图2:锁值、TTL、当前持有者与安全释放边界的关系说明图;图中表达的是静态对象关系,不是运行结果。

这把锁适合什么场景

场景建议原因
接口重复提交、短任务去重SET key token NX PX ttl一次命令完成占用和自动释放
需要主动释放token 比较后再删除避免旧请求误删新锁
任务时间不可预测续期、拆分任务或改用队列TTL 到期后互斥窗口自然结束
必须承受 Redis 故障且绝不能双持有评估更高等级的协调与业务栅栏单实例锁不自动解决故障转移和一致性问题

这套写法解决的是“单个 Redis 实例上,短时间内让同一业务键只被一个请求占用”。它不是事务,也不是永久幂等记录;如果业务必须永久拒绝重复请求,还需要数据库唯一约束或持久化的幂等状态。对长时间访问外部资源的任务,还应考虑 fencing token,不能只因为进程仍存活就假定锁一直有效。

常见问题

为什么不能先 SETNX 再 EXPIRE?

两次命令之间存在进程崩溃、超时或连接断开的窗口,锁可能只写入而没有 TTL。把 NX 与 EX/PX 放进同一个 SET 才能把抢占和过期设置作为一次命令提交。

抢锁返回空结果时应该删除旧 key 吗?

不应该。空结果说明当前条件未满足,旧 key 可能仍由其他请求持有;当前请求只能按业务策略等待、返回处理中或稍后重试。

锁过期后原请求还能释放吗?

原请求可以尝试释放,但必须先核对 token。核对失败就不要删除,因为同名 key 可能已经属于新的持有者。

参考入口:https://redis.io/docs/latest/commands/set/;单实例锁与安全释放说明:https://redis.io/docs/latest/develop/clients/patterns/distributed-locks/。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>