应使用 set key value nx px 30000 原子命令加锁，避免 setnx+expire 非原子导致死锁；释放锁必须用 lua 脚本校验 value 一致性；长任务需基于服务端时间自动续期；key 命名须含业务上下文与实例标识以防冲突。
用 SET 原子命令代替 SETNX + EXPIRE 组合
老写法是先 SETNX 再 EXPIRE，但这两步非原子：若 SETNX 成功后进程崩溃或网络中断，EXPIRE 永远不会执行，锁就永久卡住。Redis 2.6.12+ 支持带选项的 SET，直接一命搞定：SET key value NX PX 30000。其中 NX 保证仅当 key 不存在时设置，PX 30000 表示 30 秒过期，整个操作由 Redis 单线程串行执行，无竞态。
常见错误是误用 EX（秒级）而没注意业务耗时波动——比如下单平均 800ms，但偶发 GC 或 DB 慢查询拉到 3.2s，用 EX 3 就大概率提前丢锁。建议按 P99 耗时 × 2 设置 PX，并留出缓冲余量。
释放锁必须用 Lua 脚本校验 value
只靠 DEL key 是危险的：A 客户端加锁后超时释放，B 客户端拿到锁开始执行，此时 A 的释放逻辑若未加判断直接删 key，就把 B 的锁给干掉了。正确做法是用 Lua 脚本做「读-判-删」原子操作：
if redis.call("GET", KEYS[1]) == ARGV[1] then
return redis.call("DEL", KEYS[1])
else
return 0
end
脚本中 KEYS[1] 是锁 key，ARGV[1] 是加锁时生成的唯一标识（如 uuid.uuid4().hex）。这个值必须在加锁和释放时严格一致，不能硬编码、不能复用、不能从环境变量读——否则多实例会互相误删。
容易踩的坑：有人把 value 设为固定字符串（如 "locked"），看似省事，实则彻底失去持有者校验能力；还有人用时间戳当 value，但不同机器时钟不同步会导致校验失败。
避免锁续期引发的时钟漂移问题
长任务（如报表导出、批量同步）不能靠延长初始 PX 时间硬扛，得用「看门狗」机制自动续期。但别自己起守护线程调 EXPIRE——如果客户端本地时间被 NTP 调慢了 5 秒，而 Redis 服务器时间正常，你续的其实是更短的过期时间，反而加速锁失效。
可靠做法是让 Redis 自己管理续期逻辑，例如使用 Redlock 算法中的租约刷新，或直接依赖成熟封装（如 redis-py-lock 库的 auto_renewal=True 参数）。它内部用后台线程定期执行 Lua 脚本检查锁归属并重设 TTL，且 TTL 值基于服务端时间计算，不依赖客户端时钟。
性能影响：每 1/3 锁过期时间触发一次续期请求，对 Redis QPS 有轻微增加，但远低于频繁重试获取锁的开销。若任务普遍短于 500ms，其实没必要开 auto_renewal。
锁 key 命名要带业务上下文和唯一实例标识
别用 "order_lock" 这种全局静态名。一旦多个服务或多个部署环境共用一套 Redis，就会跨环境误杀。key 应包含可区分维度，例如：f"order_lock:{order_id}:{hostname}" 或 f"inventory_lock:sku_{sku_id}:shard_{shard_id}"。
特别注意容器化场景：Kubernetes Pod 重启后 hostname 可能变化，此时旧锁残留无法清理。解决方案有两个：value 中嵌入启动时间戳（如 f"{uuid4().hex}_{int(time.time())}"），或在加锁前先用 SCAN 清理本实例历史锁（代价高，慎用）。
Redis Cluster 下还要避开哈希标签陷阱：key 里含 {...} 会强制路由到同一 slot，若大量锁 key 都带相同 tag（如 "{order}lock_123"），可能造成 slot 热点。建议用业务 ID 做自然分片，而非人为打标。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
