redis分布式锁防超卖需满足：用redis-py.lock并设置timeout、blocking_timeout等参数；锁内必须用lua脚本原子执行库存判断与扣减；集群下锁与库存key须用hash tag保证同节点；锁仅保障redis层原子性，业务失败需补偿。
直接用 redis-py 的 Lock 类就能防超卖，但必须配合原子扣减逻辑，否则加锁也白加——因为锁内读+写是两步，中间若崩溃或超时，其他请求仍可能插入执行。
为什么单纯 setnx + del 会出问题
很多人一上来就写 SETNX lock:goods:123 "token"，成功后执行库存读取和 DECRBY，最后 DEL lock:goods:123。这有三个致命缺陷：
-
DEL没做持有者校验：A 进程锁过期被自动释放，B 拿到锁开始执行，A 的延迟DEL命令却把 B 的锁删了 - 没设过期时间：进程 crash 后锁永远不释放，服务彻底卡死
- 没处理重入：同一线程因重试反复 acquire，容易误删自己持有的锁
用 redis-py.Lock 必须传对的参数
redis-py 自带的 Lock 类已解决上述问题，但关键参数不能漏：
-
timeout=15：锁最大持有时间（秒），超时自动释放，防死锁 -
blocking_timeout=3：等待锁的最大时长，避免请求无限阻塞 -
thread_local=True（默认开启）：保证同一线程可重复acquire，即“可重入” - 必须搭配
socket_keepalive=True和health_check_interval=10，否则后台续期线程无法启动
示例初始化：
redis_client = Redis.from_url(
settings.REDIS_URL,
socket_keepalive=True,
health_check_interval=10
)
锁里不能只做 get + decrby
即使用了 Lock，如果还在锁内分两步操作：GET stock:123 → 判断 → DECRBY stock:123 1，依然可能超卖。原因：锁可能在 GET 后意外释放（如 GC 停顿、网络抖动），此时另一请求拿到锁并完成扣减，而前一个请求继续执行 DECRBY，导致多扣。
真正安全的做法是把判断和扣减合并进 Lua 脚本，由 Redis 原子执行：
lua_script = """
if redis.call('GET', KEYS[1]) and tonumber(redis.call('GET', KEYS[1])) >= tonumber(ARGV[1]) then
return redis.call('DECRBY', KEYS[1], ARGV[1])
else
return -1
end
"""
result = redis_client.eval(lua_script, 1, f"stock:{goods_id}", quantity)
if result == -1:
return False # 库存不足或不存在
Redis 集群下锁 key 要注意 hash tag
如果你用的是 Redis Cluster，lock:goods:123 和 stock:123 可能落在不同节点上，导致锁和数据分离——锁在 node A，库存 key 在 node B，根本起不到保护作用。
必须用 hash tag 强制它们路由到同一 slot：
- 锁 key 改为
lock:{goods:123} - 库存 key 改为
stock:{goods:123}
花括号内的内容决定 slot 计算，这样两个 key 一定在同一个节点，Lua 脚本才能安全访问。
最易被忽略的一点：锁只是第一道防线，它不保证最终一致性。如果业务逻辑中涉及数据库写入、消息投递等外部操作，锁释放后仍可能失败。所以库存扣减建议“预扣 + 异步确认”，锁只管住 Redis 层的原子读写，后续失败再补偿回滚。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
