如何在Python中使用Django处理高并发下的库存超卖问题？-Python教程-PHP中文网

select_for_update()是库存扣减的起点，因其通过数据库行锁确保并发下“查-判-改”串行执行，但必须在transaction.atomic()中调用、配合索引查询、锁内二次校验库存，并与Redis初筛及定期对账协同使用。

如何在python中使用django处理高并发下的库存超卖问题？

直接用 save() 或 update() 修改库存字段，在并发请求下必然出现超卖。根本原因是读-改-写不是原子操作：两个请求同时读到库存为 1，都判断“够扣”，然后都写回 0，实际卖出了 2 件。

select_for_update() 能在数据库层面加行锁，确保同一行库存记录在同一时刻只被一个事务修改。但它必须配合事务使用，且只在支持行锁的数据库（如 PostgreSQL、MySQL InnoDB）中有效。

必须在 transaction.atomic() 块内调用，否则锁会立即释放
不能在 get_or_404() 或普通 get() 后再调用 —— 必须用 select_for_update() 替代原始查询，例如：Product.objects.select_for_update().get(id=product_id)
如果查询条件不命中索引（比如用 name__icontains），MySQL 可能升级为表锁，严重拖慢性能

加锁只是第一步，拿到锁后仍需重新检查库存是否充足 —— 因为锁只保证“串行执行”，不保证“条件成立”。比如请求 A 拿到锁但耗时过长，期间库存已被其他事务清零，A 醒来后若不校验就直接扣减，照样超卖。

正确做法是在锁内做“查+判+改”三步，并在不满足条件时主动抛出异常或返回错误，让外层事务回滚。

不要写成：if product.stock > 0: product.stock -= 1; product.save() —— 这里 stock 是旧值，可能已过期
应该写成：if product.stock ，然后才执行 product.stock -= quantity
推荐用 F() 表达式避免竞态：例如 Product.objects.filter(id=product_id, stock__gte=quantity).update(stock=F('stock') - quantity)，但注意它不触发模型 save() 方法，也不走信号，且返回值是影响行数（0 表示扣减失败）

当并发量极高（比如万级 QPS 秒杀），全量走 Django ORM + 数据库行锁会压垮 DB。这时需要在数据库之前加一层轻量、快速的库存校验，Redis 是常见选择。

Python Hardener

通过完整的安全审查、代码整洁重构、健壮的错误处理、正确的日志记录以及完整的文档字符串覆盖，强化 Python 脚本。

下载

关键点是：校验和扣减必须原子，不能拆成 GET + DECR 两步。必须用 Lua 脚本封装，由 Redis 单线程保证原子性。

脚本示例（保存为 decr_stock.lua）：

if redis.call("GET", KEYS[1]) >= tonumber(ARGV[1]) then
  return redis.call("DECRBY", KEYS[1], ARGV[1])
else
  return -1
end

Django 中调用：result = redis_client.eval(lua_script, 1, "product:123", "1")；若 result == -1，直接拒绝下单，不进数据库事务
注意 Redis 和 DB 库存要定期对账（比如定时任务比对），因为网络分区或服务崩溃可能导致两者不一致

即使用了 select_for_update()，在 MySQL 默认的 REPEATABLE READ 隔离级别下，若查询条件未命中索引，可能触发间隙锁（gap lock），导致无关记录也被锁住，引发意外阻塞。

此外，Django 的数据库连接默认不复用，高并发下容易打满连接数，使锁等待堆积，最终超时失败。

确认库存字段有索引：至少是 db_index=True，主键查询最安全
MySQL 可临时设为 READ COMMITTED 减少间隙锁范围（需评估业务是否允许不可重复读）
调整 CONN_MAX_AGE 和连接池大小（如用 django-db-geventpool），避免频繁建连放大锁等待时间
select_for_update() 支持 nowait=True 或 skip_locked=True（PostgreSQL ≥9.5 / MySQL ≥8.0），可避免长时间阻塞，改用快速失败策略