本项目超卖问题解决

超卖现象:

1.不同的很多用户,发出请求10个,但是只有5个商品,同一时间访问

2.同一用户,在10个商品时,发出2个请求,在stock都成功

 

第一种:当读库存的时候,正常还有1个,于是2个用户都来就买,就超卖了。

1.update的时候加一个限制条件,count>1

2.

 

所谓超卖现象举例:比如某商品的库存为1,此时用户1和用户2并发购买该商品,用户1提交订单后该商品的库存被修改为0,而此时用户2并不知道的情况下提交订单,该商品的库存再次被修改为-1这就是超卖现象。

 

究其深层原因,是因为数据库底层的写操作和读操作可以同时进行,虽然写操作默认带有隐式锁(即对同一数据不能同时进行写操作)但是读操作默认是不带锁的,所以当用户1去修改库存的时候,用户2依然可以都到库存为1,所以出现了超卖现象。

解决方案:

可以对读操作加上显式锁(即在select ...语句最后加上for update)这样一来用户1在进行读操作时用户2就需要排队等待了

但是问题来了,如果该商品很热门并发量很高那么效率就会大大的下降,怎么解决?

解决方案:

我们可以有条件有选择的在读操作上加锁,比如可以对库存做一个判断,当库存小于一个量时开始加锁,让购买者排队,这样一来就解决了超卖现象。

第三种方式:加乐观锁,即更新库存时,必须更新versionId字段,若两个用户同时使得versionId =3,并提交,那么有一个用户一定被回滚。

 

乐观锁的实现


        使用数据版本(Version)记录机制实现,这是乐观锁最常用的一种实现方式。何谓数据版本?即为数据增加一个版本标识,一般是通过为数据库表增加一个数字类型的 “version” 字段来实现。当读取数据时,将version字段的值一同读出,数据每更新一次,对此version值加一。当我们提交更新的时候,判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对,如果数据库表当前版本号与第一次取出来的version值相等,则予以更新,否则认为是过期数据

   1.数据库表设计

     task

   有三个字段,分别是id,value、version

2.实现

   1)先读task表的数据(实际上这个表只有一条记录),得到version的值为versionValue

   2)每次更新task表中的value字段时,为了防止发生冲突,需要这样操作

      update task set value = newValue,version =  versionValue + 1   where version = versionValue;

      只有这条语句执行了,才表明本次更新value字段的值成功

    如假设有两个节点A和B都要更新task表中的value字段值,差不多在同一时刻,A节点和B节点从task表中读到的version值为2,那么A节点和B节点在更新value字段值的时候,都操作 update task set value = newValue,version =  3   where version = 2;,实际上只有1个节点执行该SQL语句成功,假设A节点执行成功,那么此时task表的version字段的值是3,B节点再操作update task set value = newValue,version =  3   where version = 2;这条SQL语句是不执行的,这样就保证了更新task表时不发生冲突

 

 

第二种:生成两个订单的情况

给userid 和goodsId加上唯一索引,这样插入的时候,就会报错。

  • 0
    点赞
  • 15
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值