直接用 SET key value EX seconds NX 就够用了，因其原子性保证抢锁与设过期一体完成，避免竞态和死锁，且无需依赖封装类带来的复杂风险。
为什么直接用 SET key value EX seconds NX 就够用了？
Redis 的原子命令 SET 支持 NX（不存在才设置）和 EX（设置过期时间）组合，本身就是分布式锁最简可靠的实现基础。不用额外引入 redis-py 的 Lock 类——它底层也是封装这个命令，但自带续期、释放校验等逻辑，反而容易在异常场景下锁不释放或误删他人锁。
-
NX保证只有一个客户端能抢到锁，避免竞态 -
EX防止死锁：即使客户端崩溃，锁也会自动过期 - 不要用
SETNX + EXPIRE两步，非原子操作，中间可能被中断导致无过期时间
示例（Python + redis-py）：
import redis<br>client = redis.Redis()<br>lock_key = "submit:order:123"<br>lock_value = "abc123" # 唯一标识，用于安全释放<br><br># 抢锁，10秒过期<br>if client.set(lock_key, lock_value, ex=10, nx=True):<br> try:<br> # 执行业务：查重、扣库存、写订单...<br> process_order()<br> finally:<br> # 必须校验 value 再删，防止释放别人持有的锁<br> client.eval("if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end", 1, lock_key, lock_value)
释放锁时为什么不能直接 DEL key？
直接 DEL 会破坏锁的持有者边界：A 拿到锁后执行慢，超时自动释放；B 抢到新锁开始执行；此时 A 才调用 DEL，结果把 B 的锁删了——后续其他请求就可能并发进入。
- 锁 value 必须是客户端唯一标识（如 UUID、进程 ID + 时间戳），不是固定字符串
- 释放必须用 Lua 脚本做“判断 + 删除”原子操作，Redis 保证脚本内指令不被打断
-
client.eval(...)是最稳妥方式；不要用GET + DEL两步
常见错误写法：
# ❌ 危险！可能误删<br>if client.get(lock_key) == my_lock_value:<br> client.delete(lock_key) # 中间 lock 可能已被别人更新
锁超时时间设多少才合理？
立即学习“Python免费学习笔记（深入）”；
超时时间不是越长越安全，而是要略大于「最长可能业务耗时 + 网络抖动余量」：
过短：业务还没做完锁就过期，别人进来，重复提交发生
过长：出问题后恢复慢，影响吞吐；比如设 300 秒，但实际下单平均 2 秒，那一次异常就卡住五分钟
建议先压测定位 P999 耗时（比如 1.8 秒），再加 500ms 余量 → 设
ex=2对于含外部依赖（如支付回调、短信网关）的操作，要把超时链路也纳入估算
不要硬编码，可配置化，方便上线后动态调整
Redis 单点故障会影响锁可靠性吗？
会。如果 Redis 实例宕机，所有锁丢失，相当于没锁。生产环境必须用 Redis Sentinel 或 Redis Cluster：
- Sentinel 模式下，客户端需配置
sentinel.RedisSentinel，自动发现主节点 - Cluster 模式下，注意锁 key 必须落在同一 slot（用
{xxx}包裹 key，如"{submit:order:123}"），否则EVAL脚本跨节点不支持
更关键的是：别指望 Redis 锁 100% 防重。网络分区、时钟漂移、客户端 GC 暂停都可能导致意外。真正严谨的重复提交防护，得靠数据库唯一索引（如 user_id+order_no）兜底——锁只是第一道快速拦截。
