Redis SETNX不能直接作分布式锁因无法原子设过期时间，易致死锁；应使用SET命令一次性设置key、value、EX和NX；加锁需随机value并校验，解锁须Lua脚本比对value后删除；锁需续期防超时；Redlock不推荐，单实例+正确实现更可靠。
Redis SETNX 命令为什么不能直接当分布式锁用
因为 SETNX 只能保证“设置不存在的 key”，但无法原子性地设置过期时间，导致锁可能永远不释放。常见错误是先 SETNX 再 EXPIRE，中间若进程崩溃或网络中断，锁就卡死了。
正确做法是用 Redis 2.6.12+ 的 SET 命令一次性完成：key、value、过期时间、仅当不存在才设置（nx）四个条件。例如：
SET lock:order:123 "client_abc" EX 30 NX
其中 "client_abc" 是唯一客户端标识，必须带；EX 30 表示 30 秒自动释放，避免死锁；NX 保证互斥。
Python redis-py 怎么安全实现加锁和解锁
加锁要用 set() 方法传入 nx=True、ex= 和 value= 参数，不能只靠 setnx()；解锁必须校验 value 是否匹配，再用 Lua 脚本删除——否则可能误删别人持有的锁。
立即学习“Python免费学习笔记（深入）”；
- 加锁时生成随机字符串（如
uuid.uuid4().hex）作为value，存进 Redis，同时记录到本地变量 - 解锁必须用 Lua 脚本原子执行：“如果 key 存在且值等于当前 client id，才 DEL”
- 别用
del命令直接删，否则 A 拿着过期锁还没删，B 新建了同名锁，A 一删就把 B 的锁干掉了
示例 Lua 解锁脚本：
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
if redis.call("GET", KEYS[1]) == ARGV[1] then
return redis.call("DEL", KEYS[1])
else
return 0
end
锁自动过期后业务还没执行完怎么办
这是分布式锁最常被忽略的现实问题：锁续期（renewal）不是可选项，而是必选项。Redis 自身不支持“延长 TTL”，只能靠客户端主动刷新。
推荐方案是启动一个守护线程（或 asyncio task），在锁剩余生命周期 1/3 时尝试用 Lua 脚本更新过期时间，前提是 value 仍匹配：
if redis.call("GET", KEYS[1]) == ARGV[1] then
return redis.call("EXPIRE", KEYS[1], ARGV[2])
else
return 0
end
- 续期间隔建议设为
min(锁总时长 // 3, 5)秒，太频繁增加 Redis 压力，太慢容易断 - 守护线程必须和业务逻辑共用同一个 client id，且在线程退出前主动解锁
- 如果业务本身耗时不可控（比如调外部 API），锁时长不能拍脑袋定，得结合 P99 延迟 + 安全余量
Redlock 算法在 Python 里值得上吗
不推荐。Redlock 理论上通过多数派节点提升容错，但实际中它依赖严格的时间同步，而多数生产环境 NTP 漂移 >100ms，Redis 主从复制也有延迟，反而让锁更不可靠。
绝大多数 Web 场景只需单 Redis 实例 + 正确的 SET + Lua 解锁 + 续期机制。除非你有跨机房强一致性要求，且愿意投入运维成本维护 5 个独立 Redis 实例，否则 Redlock 带来的复杂度远超收益。
真正关键的是：锁粒度要细（比如锁 order:123 而不是 order）、锁失败要快速降级（如返回“稍后重试”而非卡住）、所有路径都要有超时和兜底清理逻辑。
