- 在多个用户同时发起对同一个商品的下单请求时,先查询商品库存,再修改商品库存,会出现资源竞争问题,导致库存的最终结果出现异常。
解决方法:
使用乐观锁或悲观锁
- 乐观锁
- 悲观锁
二、乐观锁
总是认为不会产生并发问题,每次去取数据的时候总认为不会有其他线程对数据进行修改,因此不会上锁,但是在更新时会判断其他线程在这之前有没有对数据进行修改。乐观锁并不是真实存在的锁,而是在更新的时候判断此时的库存是否是之前查询出的库存,如果相同,表示没人修改,可以更新库存,否则表示别人抢过资源,不再执行库存更新。
三、悲观锁
总是假设最坏的情况,每次取数据时都认为其他线程会修改,所以都会加锁(读锁、写锁、行锁等),当其他线程想要访问数据时,都需要阻塞挂起。可以依靠数据库实现,如行锁、读锁和写锁等,都是在操作之前加锁。悲观锁类似于我们在多线程资源竞争时添加的互斥锁,容易出现死锁现象,采用不多。
四、例子
乐观锁:
'''乐观锁下订单(存在事务管理)'''
class TradeCommitView_le(View):
@transaction.atomic
def post(self, request):
'''设置保存点用于事务管理'''
sid1 = transaction.savepoint()
user = request.user
if not user.is_authenticated():
'''判断是否登陆'''
return redirect(reverse('car:index'))
# 接收数据
car_id = request.POST.get('car_id')
pay_method = request.POST.get('pay_style')
address_id = request.POST.get('address')
from datetime import datetime
order_id = str(user.id) + datetime.now().strftime('%Y%m%d%H%M%S')
# 运费(元)
transport = 5000
if not all(