一、问题分析：
在多个用户同时发起对同一个商品的下单请求时，先查询商品库存，再修改商品库存，会出现资源竞争问题，导致库存的最终结果出现异常。
正如下面这张图：甲、乙同时下单购买A商品，下单前都查到库存都为15，而下单时，甲稍快些买走了10件，实际库存还剩5件，而乙下单时，仍然用库存15来判断，最终会导致商品库存大于售出。
二、解决思路
- 悲观锁
当查询某条记录时，即让数据库为该记录加锁，锁住记录后别人无法操作，使用类似如下语法
select stock from tb_sku where id=1 for update;
SKU.objects.select_for_update().get(id=1)
悲观锁类似于我们在多线程资源竞争时添加的互斥锁，容易出现死锁现象，当A锁定了a资源，需要b资源。而b资源又被B锁定了，正在等待a资源。此时就导致了死锁。我们一般通过设置超时时间来处理这个问题。
- 乐观锁
乐观锁并不是真实存在的锁，而是在更新的时候判断此时的库存是否是之前查询出的库存，如果相同，表示没人修改，可以更新库存，否则表示别人抢过资源，不再执行库存更新。类似如下操作
update tb_sku set stock=2 where id=1 and stock=7;
SKU.objects.filter(id=1, stock=7).update(stock=2)
- 任务队列
将下单的逻辑放到任务队列中（如celery），将并行转为串行，所有人排队下单。比如开启只有一个进程的Celery，一个订单一个订单的处理。
然后，我们现在解决了锁的问题，全部请求采用“先进先出”的队列方式来处理。那么新的问题来了，高并发的场景下，因为请求很多，很可能一瞬间将队列内存“撑爆”，然后系统又陷入到了异常状态。或者设计一个极大的内存队列，也是一种方案，但是，系统处理完一个队列内请求的速度根本无法和疯狂涌入队列中的数目相比。也就是说，队列内的请求会越积累越多，最终Web系统平均响应时候还是会大幅下降，系统还是陷入异常。
因此最好的方式还是采用乐观锁。
另附web项目中秒杀、抢购的实现原理及实现方式
https://blog.csdn.net/cyy_zyd/article/details/81741751