避免商品超卖的4种方案

原始方案(失败):在每次下订单前我们判断促销商品的数量够不够,不够不允许下订单,更改库存量时加上一个条件,只更改商品库存大于0的商品的库存,当时我们使用ab进行压力测试,当并发超过500,访问量超过2000时,还是会出现超卖现象。

public function buyOne()
{
    $shop = Shop::find(1);
    if ($shop->number > 0) {
        DB::update("update shop set number = number - 1 where id = 1");
    }
}

第1种方案:使用mysql的事务加排他锁来解决,首先我们选择数据库的存储引擎为innoDB,使用的是排他锁实现的,刚开始的时候我们测试了下共享锁,发现还是会出现超卖的现象。有个问题是,当我们进行高并发测试时,对数据库的性能影响很大,导致数据库的压力很大。

//2.利用数据库的forupdate来加锁(在数量少的情况下并不会出现问题,但是当并发达到(ab -n 1000 -c 200),
//就会出现请求非2XX的响应增多,1000 失败了 60)time per request 65.195
//在高并发的情况下,会导致数据库连接数不够,部分php获取不到连接而报错,或者是超过等待时间而报错

public function indexMysql() {
  DB::beginTransaction();
  //通过for update 加排它锁
  $shop = DB::table(‘shop‘)->where(‘id‘, ‘=‘, 1)->lockForUpdate()->first();
  if ($shop->number > 0) {
    if (DB::update("update shop set number = number - 1 where id = 1")) {
      DB::commit();
    } else {
      DB::rollBack();//回滚并重试
      usleep(100000);
      $this->indexMysql();
    }
  } else {
    DB::commit();
  }
}

第2种方案:使用文件锁实现。当用户抢到一件促销商品后先触发文件锁,防止其他用户进入,该用户抢到促销品后再解开文件锁,放其他用户进行操作。这样可以解决超卖的问题,但是会导致文件得I/O开销很大。

第3种方案:使用redis的setnx来实现锁机制。但是并发大的情况下,锁的争夺会变多,导致响应越来越慢。(与第四种方案类似)

//在数量少的情况下并不会出现问题,但是当并发达到(ab -n 1000 -c 200 就会出现请求非2XX的响应增多,1000 失败了 54) time per request 127.575

public function index() {
  //测试并发超卖现象
  if (Redis::setnx(self::KEY, 1)) {//拿到了锁
    $this->buy();
  } else {
    usleep(100000);//等会再去拿锁
    //Log::info("未争夺到锁,睡眠100ms");
    $this->index();
  }
}
private function buy() {
  $shop = Shop::find(1);
  if ($shop->number > 0) {
    $shop->number --;
    $shop->save();
  }
  Redis::del(self::KEY);
}

第4种方案:redis的队列来实现。将要促销的商品数量以队列的方式存入redis中,每当用户抢到一件促销商品则从队列中删除一个数据,确保商品不会超卖。这个操作起来很方便,而且效率极高

//4.使用redis队列来,用户过来直接入队列,然后再将操作更新到数据库
//最佳体验(redis pconnect 9.481s, 无丢失, 无框架)

public function push() {
  //入队列
  Redis::lpush(self::QUEUE, 1);
}

//脚本调用pop方法 * * * * * php xxx.php

public function pop()
{
    while (($key = Redis::rpop(self::QUEUE))) {
      $shop = Shop::find(1);
      if ($shop->number > 0) {
        DB::update("update shop set number = number - 1 where id =         1")
     }
  }
}

原文地址:https://www.cnblogs.com/dawuge/p/10480469.html

时间: 2024-10-09 10:12:13

避免商品超卖的4种方案的相关文章

以商品超卖为例讲解Redis分布式锁

本案例主要讲解Redis实现分布式锁的两种实现方式:Jedis实现.Redisson实现.网上关于这方面讲解太多了,Van自认为文笔没他们好,还是用示例代码说明. 一.jedis 实现 该方案只考虑Redis单机部署的场景 1.1 加锁 1.1.1 原理 jedis.set(String key, String value, String nxxx, String expx, int time) key: 使用key来当锁,因为key是唯一的; value: 我传的是唯一值(UUID),很多童鞋

订单并发商品超卖问题解决

问题:商品超卖(库存数出现负数). 模拟并发: goods商品表: /** * 下单 * @return string * @throws \yii\db\Exception */ public function actionIndex() { $redis = Yii::$app->redis; // 使用redis做一些统计 $redis->incr('total'); // 自增(记录一共成功进来了多少个请求) //$redis->del('total'); //$redis-&g

商城商品超卖处理

首先环境介绍下:商城商品可能存在几个端(PC.APP),其次每个端对应的服务端又可能做了负载均衡(即也有多个服务端). 要实现的目标和功能:保证商品不会出现超卖的情况.超卖商品后,无法对商品进行发货,是一种不负责任的行为. 方案实现讨论流程 "要实现不超卖,首先商品库存的扣减不能使用框架进行更新,因为框架是设置值,如果在这段时间,又有人购买了,则商品库存必然会出现问题.要采用手写SQL方式.并且sql中还要判断是否大于等于指定的购买量." UPDATE `SKU_Info` SET s

超卖频发or商品滞销?压倒卖家的最后一根稻草竟是库存!

超卖频发or商品滞销?压倒卖家的最后一根稻草竟是库存! 云南逸神生态茶业有限公司便是一家从最初的单体销售到目前的生产.加工.销售一体化经营,并拥有60多家遍布云南省内.省外城市的直营专卖店.想要发展壮大,除了产品品质之外,更重要的是方法,拥有60多家门店的"逸神"已经出现了库存不准导致的商品超卖,商品滞销带来的库存积压,如无法解决这些问题,发展壮大只能是个遥远的梦.逸神管理者具有长远的眼光,他认为想要把逸神发展成为更大的连锁企业,不仅依靠逸神的销售团队,同时还要借助先进的管理工具实现对

对于业务中库存超卖测试

多并发时,用相应的锁方案保证库存不发生超卖.实现这个方案后,要有相应的场景测试方案. 很多时候,验证方案非常重要. java可以利用CountDownLatch测试多并发.CountDownlatch通常用于某个业务线程需要等待其它多个线程完成某个条件后才进行相应操作. CountDownLatch有countDown及await方法,分别对应减少计数器及当计数器大于0时阻塞当前线程.当计数量等于0时所有调用await方法且被阻塞的线程都被唤醒,然后进行相应操作. 此处用于模拟10个并发用户进行

关于JAVA中HashMap集合的的三种超不好记的便利方案

HashMap 和 HashSet 是 Java Collection Framework 的两个重要成员,其中 HashMap 是 Map 接口的常用实现类 1:先创建一个类 1 package Day; 2 3 import java.util.ArrayList; import java.util.HashMap; import java.util.Iterator; import java.util.Map; import java.util.Map.Entry; import java

秒杀的性能和超卖

一.秒杀带来了什么? 秒杀或抢购活动一般会经过[预约][抢订单][支付]这3个大环节,而其中[抢订单]这个环节是最考验业务提供方的抗压能力的. 抢订单环节一般会带来2个问题: 1.高并发 比较火热的秒杀在线人数都是10w起的,如此之高的在线人数对于网站架构从前到后都是一种考验. 2.超卖 任何商品都会有数量上限,如何避免成功下订单买到商品的人数不超过商品数量的上限,这是每个抢购活动都要面临的难题. 二.如何解决? 首先,产品解决方案我们就不予讨论了.我们只讨论技术解决方案 1.前端 面对高并发的

关于秒杀和超卖的性能问题

一.秒杀带来了什么? 秒杀或抢购活动一般会经过[预约][抢订单][支付]这3个大环节,而其中[抢订单]这个环节是最考验业务提供方的抗压能力的. 抢订单环节一般会带来2个问题: 1.高并发 比较火热的秒杀在线人数都是10w起的,如此之高的在线人数对于网站架构从前到后都是一种考验. 2.超卖 任何商品都会有数量上限,如何避免成功下订单买到商品的人数不超过商品数量的上限,这是每个抢购活动都要面临的难题. 二.如何解决? 首先,产品解决方案我们就不予讨论了.我们只讨论技术解决方案 1.前端 面对高并发的

如何解决秒杀的性能问题和超卖的讨论

如何解决秒杀的性能问题和超卖的讨论 最近业务试水电商,接了一个秒杀的活.之前经常看到淘宝的同行们讨论秒杀,讨论电商,这次终于轮到我们自己理论结合实际一次了. ps:进入正文前先说一点个人感受,之前看淘宝的ppt感觉都懂了,等到自己出解决方案的时候发现还是有很多想不到的地方其实都没懂,再次验证了“细节是魔鬼”的理论.并且一个人的能力有限,只有大家一起讨论才能想的更周全,更细致.好了,闲话少说,下面进入正文. 一.秒杀带来了什么? 秒杀或抢购活动一般会经过[预约][抢订单][支付]这3个大环节,而其