redis-py的lock()方法不够用，因其依赖单节点Redis且主从异步复制下易丢锁；加锁须用SET key value EX NX原子命令，释放必须通过Lua脚本比对value防误删，续期需后台线程安全更新，value须全局唯一并严格校验。
为什么直接用 redis-py 的 lock() 方法不够用
它默认依赖单节点 Redis，且在主从异步复制场景下可能丢失锁（比如客户端拿到锁后主节点宕机，从节点升主但没同步该锁，另一个客户端又拿到同名锁）。更关键的是，它的自动续期（extend()）和中断处理不透明，线上出问题时很难定位是锁没释放、还是续期失败导致提前过期。
实际业务中你需要：可指定连接池、支持多实例容错、能记录加锁/释放轨迹、失败时明确抛出哪类异常。所以得自己封装，而不是直接套 redis.lock()。
如何设计一个带租约续期和原子释放的锁类
核心是两件事：加锁必须用 SET key value EX seconds NX 命令保证原子性；释放必须用 Lua 脚本比对 value（防止误删别人持有的锁）；续期得靠后台线程定期调用 GETSET 或 EVAL 更新过期时间，且要检查当前锁是否仍由本实例持有。
-
value必须是全局唯一标识（如f"{os.getpid()}-{threading.get_ident()}-{uuid.uuid4().hex[:8]}"），不能用时间戳或随机数而无上下文 - 构造时传入
redis.ConnectionPool而非Redis实例，避免连接复用冲突 - 加锁方法应支持
timeout（获取锁最长等待时间）和lease_time（锁自动过期时间），二者语义不同，不能混用 - 释放失败不应静默吞掉——若 Lua 返回 0，应抛出
RuntimeError("lock not owned by current client")
分布式环境下怎么防止锁被意外释放
最常见错误是：用 del key 直接删，结果删了别人刚续期成功的锁。或者用 get + del 两步操作，中间被抢占。
正确做法只有一条：所有释放逻辑必须走同一段 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
这个脚本必须通过 redis.eval(script, 1, lock_key, lock_value) 调用，且 lock_value 必须和加锁时一致。任何绕过该脚本的释放方式都不可靠。
另外注意：redis-py 的 register_script() 可缓存脚本 SHA，减少网络开销，建议在类初始化时就注册好。
Redis 连接中断或命令超时怎么办
锁操作不是“尽力而为”，而是“必须明确成败”。因此每个 Redis 调用都要设 socket_timeout 和 socket_connect_timeout（建议均设为 100~500ms），并捕获 redis.ConnectionError、redis.TimeoutError、redis.RedisError。
- 加锁时遇到连接异常，不能假设锁没拿到——得查一次 key 是否已存在且 value 匹配，再决定是否重试
- 续期线程如果连不上 Redis，应停止续期并标记锁为“可能已失效”，后续释放动作需跳过（避免释放一个其实已过期的锁）
- 生产环境建议搭配
redis-sentinel或redis-cluster客户端，不要硬写 failover 逻辑
真正难的从来不是写对一行 SET 命令，而是当网络分区发生时，你能否说清此刻锁到底在谁手里、有没有被重复授予、以及下游服务该怎么降级。这些边界情况，光靠封装一个类解决不了，得结合监控和日志埋点来看。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
