某生鲜电商平台的库存扣减方案

猿天地

共 6181字,需浏览 13分钟

 ·

2020-07-28 16:51

一、 问题

一件商品只有100个库存,现在有1000或者更多的用户来购买,每个用户计划同时购买1个到几个不等商品。

如何保证库存在高并发的场景下是安全的?

(1)不多发

(2)不少发

二、 下单的步骤

(1)下单

(2)下单同时预占库存

(3)支付

(4)支付成功真正减扣库存

(5)取消订单

(6)回退预占库存

三、 什么时候进行预占库存?

(1)方案一:加入购物车的时候去预占库存

(2)方案二:下单的时候去预占库存

(3)方案三:支付的时候去预占库存

四、 分析

(1)方案一:加入购物车并不代表用户一定会购买,如果这个时候开始预占库存,会导致想购买的无法加入购物车。而不想购买的人一直占用库存。显然这种做法是不可取的。

(2)方案二:商品加入购物车后,选择下单,这个时候去预占库存。用户选择去支付说明了,用户购买欲望是比 方案一 要强烈的。订单也有一个时效,例如半个小时。超过半个小时后,系统自动取消订单,回退预占库存。

(3)方案三:下单成功去支付的时候去预占库存。只有100个用户能支付成功,900个用户支付失败。用户体验不好,就像你走了一条光明大道,一路通畅,突然被告知此处不通行。而且支付流程也是一个比较复杂的流程,如果和减库存放在一起,将会变的更复杂。

所以综上所述:选择方案二比较合理。

五、 重复下单问题

(1)用户点击过快,重复提交两次

(2)网络延时,用户刷新或者点击下单重复提交

(3)网络框架重复请求,某些网络框架,在延时比较高的情况下会自动重复请求

(4)用户恶意行为

六、 解决办法

在UI拦截,点击后按钮置灰,不能继续点击,防止用户,连续点击造成的重复下单。

1、在下单前获取一个下单的唯一token,下单的时候需要这个token。后台系统校验这个 token是否有效,才继续进行下单操作。

/**     

* 先生成 token 保存到 Redis     

* token 作为 key , 并设置过期时间 时间长度 根据任务需求     

* value 为数字 自增判断 是否使用过      *     

* @param user     

* @return   

*/

public String createToken(User user) {
    String key = "placeOrder:token:" + user.getId();
    String token = UUID.randomUUID().toString();
    //保存到Redis
    redisService.set(key + token, 0, 1000L);
    return token;
}

/**     

* 校验下单的token是否有效     

* @param user     

* @param token     

* @return     

*/

public Boolean checkToken(User user, String token) {
    String key = "placeOrder:token:" + user.getId();
    if (null != redisService.get(key + token)) {
        long times = redisService.increment(key + token, 1);
        if (times == 1) {
            //利用increment 原子性 判断是否 该token 是否使用
            return true;
        } else {
            // 已经使用过了

        }

        //删除
        redisService.remove(key + token);
    }

    return false;
}

2、如何安全的减扣库存?

同一个用户或者多个用户同时抢购一个商品的时候,我们如何做到并发安全减扣库存?

(1)数据库操作商品库存

public interface ProductDao extends JpaRepository {

    /**
     * @param pid 商品ID
     * @param num 购买数量
     * @return
     */

    @Transactional
    @Modifying
    @Query("update Product set availableNum = availableNum - ?2 , reserveNum = reserveNum + ?2 where id = ?1")
    intreduceStock1(Integerpid, Integernum);

    /**
     * @param pid 商品ID
     * @param num 购买数量
     * @return
     */
    @Transactional
    @Modifying
    @Query("update Product set availableNum = availableNum - ?2 , reserveNum = reserveNum + ?2 where id = ?1 and  availableNum - ?2 >= 0")
    intreduceStock2(Integerpid, Integernum);

}

(2)下单

 /**
  * 下单操作1
  *
  * @param req
  */
  private int place(PlaceOrderReq req) {
      User user = userDao.findOne(req.getUserId());
      Product product = productDao.findOne(req.getProductId());
      //下单数量
      Integer num = req.getNum();
      //可用库存
      Integer availableNum = product.getAvailableNum();
      //可用预定
      if (availableNum >= num) {
          //减库存
          int count = productDao.reduceStock1(product.getId(), num);
          if (count == 1) {
              //生成订单
              createOrders(user, product, num);
          } else {
              logger.info("库存不足 3");
          }
          return 1;

      } else {
          logger.info("库存不足 4");
          return -1;
      }

  }

/**
  * 下单操作2
  *
  * @param req
  */
private int place2(PlaceOrderReq req) {
    User user = userDao.findOne(req.getUserId());
    Product product = productDao.findOne(req.getProductId());
    //下单数量 
    Integer num = req.getNum();
    //可用库存
    Integer availableNum = product.getAvailableNum();
    //可用预定
    if (availableNum >= num) {
        //减库存
        int count = productDao.reduceStock2(product.getId(), num);
        if (count == 1) {
            //生成订单
            createOrders(user, product, num);
        } else {
            logger.info("库存不足 3");
        }
        return 1;

    } else {
        logger.info("库存不足 4");
        return -1;
    }
}

方法1:不考虑库存安全的写法

/**
* 方法 1      
* 减可用
* 加预占
* 库存数据不安全     
* @param req
*/
@Override
@Transactional
public void placeOrder(PlaceOrderReq req) {
    place1(req);
}

分析:在高并的场景下,假设库存只有 2 件 ,两个请求同时进来,抢购改商品,购买数量都是 2. A请求 此时去获取库存,发现库存刚好足够,执行扣库存下单操作。在 A 请求为完成的时候(事务未提交),B请求 此时也去获取库存,发现库存还有2. 此时也去执行扣库存,下单操作。库存剩 2 ,但是卖出了 4 。最终数据库库存数量将变为 -2 ,所以库存是不安全的。

方法2:这个操作可以保证库存数据是安全的

/**
* 方法 2      
* 减可用      
* 加预占      
* 库存数据不安全      
* @param req
*/
@Override
@Transactional
public void placeOrder(PlaceOrderReq req) {
    place2(req);
}

分析:在方法1 的基础上 ,更新库存的语句,增加了可用库存数量 大于 0, availableNum - num >= 0 ;实质是使用了数据库的乐观锁来控制库存安全,在并发量不是很大的情况下可以这么做。但是如果是秒杀,抢购,瞬时流量很高的话,压力会都到数据库,可能拖垮数据库。

方法3:该方法也可以保证库存数量安全

/**   

* 方法 3     

* 采用 Redis 锁  通一个时间 只能一个 请求修改 同一个商品的数量     

     

* 缺点并发不高,同时只能一个用户抢占操作,用户体验不好!      *     

* @param req     

*/

@Override
public void placeOrder2(PlaceOrderReq req) {
    String lockKey = "placeOrder:" + req.getProductId();
    Boolean isLock = redisService.lock(lockKey);
    if (!isLock) {
        logger.info("系统繁忙稍后再试!");
        return 2;
    }

    //place2(req); place1(req);

    //这两个方法都可以
    redisService.unLock(lockKey);
}

分析:利用Redis 分布式锁, 强制控制 同一个商品,同时只能一个请求处理下单。其他请求返回 ‘系统繁忙稍后再试!’;强制把处理请求串行化,缺点并发不高 ,处理比较慢,不适合抢购等方案 。用户体验也不好,明明看到库存是充足的,就是强不到。相比方案2减轻了数据库的压力。

方法4 :可以保证库存安全,满足高并发处理,但是相对复杂一点

/**     

* 方法 4     

* 商品的数量 等其他信息 先保存 到 Redis     

* 检查库存 与 减少库存 不是原子性,  以 increment > 0 为准      *     

* @param req     

*/

@Override   
public void placeOrder3(PlaceOrderReq req) {
    String key = "product:" + req.getProductId();
    // 先检查 库存是否充足
    Integer num = (Integer) redisService.get(key);
    if (num < req.getNum()) {
        logger.info("库存不足 1");
    } else{
        //不可在这里下单减库存,否则导致数据不安全, 情况类似 方法1;
    }

    //减少库存
    long value = redisService.increment(key, -req.getNum().longValue());

    //库存充足
    if (value >= 0) {
        logger.info("成功抢购 ! ");
        //TODO 真正减 扣 库存 等操作 下单等操作  ,这些操作可用通过 MQ 或 其他方式
        place2(req);
     } else {
        //库存不足,需要增加刚刚减去的库存
        redisService.increment(key, req.getNum().longValue());
        logger.info("库存不足 2 ");
    }
}

分析:利用Redis increment 的原子操作,保证库存安全。事先需要把库存的数量等其他信息保存到Redis,并保证更新库存的时候,更新Redis。

进来的时候 先 get 库存数量是否充足,再执行 increment。以 increment > 0 为准。检查库存 与 减少库存 不是原子性的。检查库存的时候技术库存充足也不可下单;否则造成库存不安全,原来类似 方法1. increment 是个原子操作,已这个为准。

redisService.increment(key, -req.getNum().longValue()) >= 0 说明库存充足,可以下单。

redisService.increment(key, -req.getNum().longValue()) < 0 的时候 不能下单,次数库存不足。并且需要 回加刚刚减去的库存数量,否则会导致刚才减扣的数量 一直买不出去。数据库与缓存的库存不一致。

次方法可以满足 高并抢购等一些方案,真正减扣库存和下单可以异步执行。

订单时效问题,订单取消等 为保证商家利益,同时把商品卖给有需要的人,订单下单成功后,往往会有个有效时间。超过这个时间,订单取消,库存回滚。

订单取消后,可利用MQ 回退库存等。

相关推荐



后台回复 学习资料 领取学习视频


如有收获,点个在看,诚挚感谢

浏览 45
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报