Redlock 在 Python 中不应直接使用 PyPI 的 redlock-py，因其未遵循修正建议、存在竞态漏洞；应手写核心逻辑或选用经审计的 redlock-python 0.3.x 分支，且必须校验有效节点数、补偿时钟漂移、独立连接池、Lua 安全解锁。
Redlock 在 Python 里不能直接 pip install redlock
PyPI 上的 redlock-py 库不是官方实现，也不完全遵循 Martin Kleppmann 对 Redlock 的原始质疑后提出的修正建议。它默认使用固定重试间隔、忽略时钟漂移补偿、且锁续期逻辑有竞态漏洞。真实分布式场景下，用它容易出现「以为加锁成功，其实没锁住」的情况。
- 真正该用的是
redis-py自带的Lock类——但它只是单 Redis 实例锁，不满足 Redlock 多节点要求 - 若坚持 Redlock 模式，推荐手写核心逻辑，或用经过审计的轻量封装（如
redlock-python的 0.3.x 分支，非 PyPI 主流版本） - 更务实的选择：先确认是否真需要 Redlock——90% 的业务用 Redis 单实例 +
SET key value EX seconds NX配合合理的超时和幂等设计已足够
Redlock 正确实现必须校验「有效节点数」而非「响应数」
常见错误是只要收到 N/2+1 个 Redis 节点的「OK」就认为加锁成功。但 Redlock 要求的是：在「同一客户端视角的锁获取时间窗口内」，有 ≥ N/2+1 个节点成功设置锁，且每个节点的剩余 TTL > 0 —— 这个 TTL 必须扣除网络延迟与本地时钟误差。
- 每次向 Redis 发起
SET key value EX seconds NX后，立刻记录本地时间戳start_time - 收到响应后，计算
rtt = time.time() - start_time，再用ttl_remaining = requested_ttl - rtt - clock_drift判断是否有效 -
clock_drift建议设为 1–2ms（局域网），跨可用区至少 5ms；不能省略，否则时钟不同步时锁会提前失效 - 最终有效节点数 = 满足
ttl_remaining > 0的节点数量，不是响应数量
Redis 连接池配置不当会导致 Redlock 误判
Redlock 要求对多个 Redis 节点并发请求，如果共用同一个连接池或未限制最大连接数，高并发下会出现连接阻塞、RTT 波动剧烈，进而让 ttl_remaining 计算失真，触发假失败。
- 每个 Redis 节点必须独立配置连接池：
ConnectionPool(max_connections=10, socket_timeout=0.1) -
socket_timeout必须显式设为远小于锁超时值（比如锁设 10s，timeout 设 0.1s），否则一个节点卡住会拖垮整个 Redlock 流程 - 禁用
retry_on_timeout=True—— Redlock 不允许自动重试，重试必须由上层逻辑控制并重新计时 - 避免使用
redis.Redis(connection_pool=shared_pool)共享池，这是最常被忽略的性能陷阱
解锁必须用 Lua 脚本，且只删「自己设的值」
解锁时若用 DEL key，可能误删其他客户端的锁；若用 GET + DEL 两步，中间会被抢占。唯一安全方式是原子 Lua 脚本，且脚本必须比对 value。
立即学习“Python免费学习笔记（深入）”；
if redis.call("GET", KEYS[1]) == ARGV[1] then
return redis.call("DEL", KEYS[1])
else
return 0
end- Python 中调用：
redis.eval(lua_script, 1, key, lock_value)，其中lock_value是加锁时生成的唯一随机字符串（推荐uuid.uuid4().hex） - 不能用时间戳或进程 ID 作 value——它们不全局唯一，多实例部署时极易冲突
- 解锁失败返回 0 时，不要重试：Redlock 规范明确要求「解锁失败即放弃」，重试只会扩大不确定性
Redlock 真正难的不是代码怎么写，而是你得清楚知道：每个 Redis 节点的物理位置、网络 RTT 分布、时钟同步状态，以及业务能容忍的锁失效窗口。这些信息不进代码，只进运维台账。
