Django解决订单并发问题：悲观锁与乐观锁实战

并发场景下的库存竞争

在电商系统中，多用户同时下单同一商品是常见的并发场景。如果处理不当，先查询库存再修改库存的逻辑会导致库存结果异常，甚至出现超卖现象。解决这一问题的核心在于如何管理数据库层面的资源竞争。

方案一：悲观锁（Pessimistic Locking）

悲观锁的核心思想是“先锁定，后操作”。在查询记录时直接锁定该行数据，阻止其他事务对该记录的修改。这种方式类似于多线程编程中的互斥锁（Mutex）。

Django 实现方式

Django ORM 提供了 select_for_update() 方法来实现数据库层面的行级锁。当查询语句中包含此方法时，生成的 SQL 会带有 FOR UPDATE 子句。

# 原始 SQL 示例
select stock from tb_sku where id=1 for update;

# Django ORM 实现
SKU.objects.select_for_update().get(id=1)

注意事项：虽然悲观锁能确保数据一致性，但在高并发场景下容易引发死锁现象，且会阻塞其他事务的执行，可能导致系统吞吐量下降。因此，需权衡锁的粒度与业务性能。

方案二：乐观锁（Optimistic Locking）

乐观锁并非数据库底层提供的真实锁机制，而是一种应用层的并发控制策略。它假设冲突发生的概率较低，因此在更新时不预先锁定数据，而是通过判断数据是否被修改来决定是否执行更新。

实现逻辑

1. 查询：读取当前库存值（例如 7）。
2. 更新：在执行 UPDATE 语句时，增加条件判断，要求当前库存值必须与查询时一致。
3. 结果：若库存已被其他事务修改，则更新语句影响的行数为 0，业务层可据此判断更新失败并处理重试或报错。

Django 实现方式

利用 Django 的 filter() 方法在更新时附加库存条件，实现原子性检查。

# 原始 SQL 示例
update tb_sku set stock=2 where id=1 and stock=7;

# Django ORM 实现
SKU.objects.filter(id=1, stock=7).update(stock=2)

这种方式避免了数据库锁带来的死锁风险，适合读多写少或冲突概率较低的场景。

方案三：任务队列串行化

除了数据库层面的锁机制，还可以通过应用层架构调整来解决并发问题。将并行下单请求转化为串行处理，是另一种有效的解决思路。

Celery 任务队列

使用 Celery 等任务队列中间件，可以将下单请求放入队列中。通过开启单进程模式的 Celery Worker，可以确保订单处理逐个执行，从而在逻辑上消除并发竞争。

• 用户提交订单后，不直接操作数据库，而是发送消息到队列。
• Celery Worker 按顺序从队列中取出任务并执行。
• 由于是串行处理，天然避免了并发冲突。

权衡建议：串行化处理会降低系统的响应速度和吞吐量，适用于对实时性要求不高但强一致性的场景。对于高并发场景，通常推荐结合乐观锁与限流降级策略。

总结

解决 Django 中的订单并发问题，需根据业务场景选择合适策略：追求强一致性且冲突少时可选乐观锁；对数据一致性要求极高且可接受一定性能损耗时可选悲观锁；若系统架构允许，串行化处理是最彻底的解决方案。实际生产中，往往需要组合使用多种策略以达到最佳效果。

以上就是Django解决订单并发问题的详细内容，更多关于Django并发处理、数据库锁机制的资料请关注本站其它相关文章！