JAVA面试题分享一百一十八：JAVA商品库存管理如何防止超卖？如何解决超卖？

一、分析

在商品库存管理中，超卖是指销售数量超过了实际库存数量的情况。这在电商和其他零售业务中是一个常见的问题。为了防止和解决超卖问题，可以采取以下策略：

1. 数据库级别的锁定:
   使用数据库的乐观锁或悲观锁来确保在读取和更新库存量时的数据一致性。这可以确保在并发操作中，只有一个操作可以成功修改库存。
2. 减少数据库的读写延迟:
   使用如Redis这样的内存数据库来缓存库存数据，从而加速读写操作。但需要注意的是，缓存和数据库之间的数据同步问题。
3. 分布式锁:
   如果你的应用是分布式的，考虑使用分布式锁来确保跨多个实例的库存操作的原子性。
4. 队列和限制并发:
   使用消息队列来管理库存操作，限制并发的库存更新请求。这可以确保请求按顺序被处理，从而防止超卖。
5. 预先分配库存:
   在大型促销活动中，可以为每个渠道或每个时间段预先分配一定量的库存。这确保了在活动开始时的并发高峰不会导致超卖。
6. 后端验证:
   在订单生成之前，再次验证库存数量。即使前端已经进行了检查，后端也应该再次验证以确保数据的准确性。
7. 设置库存阈值:
   当库存量达到一个预设的阈值时，自动将商品下架或标记为不可售，从而防止进一步的销售。
8. 监控和警报:
   定期检查和分析系统的销售和库存数据，查找可能的超卖情况。如果发现超卖，立即进行调查并修复问题。
9. 日志记录:
   记录所有与库存相关的操作，以便在发生超卖时可以追踪和定位问题的根源。
10. 回滚策略:
    如果发现超卖情况，有一套回滚策略，例如取消部分订单，以确保库存数据的准确性。
11. 补偿机制:
    对于因超卖而受影响的客户，提供适当的补偿，例如优惠券、积分或其他形式的补偿。

总之，防止和解决超卖问题需要结合多种策略和技术手段。重要的是要根据自己的业务场景和技术栈选择最合适的方案，并不断地监控和优化系统以确保数据的准确性和客户的满意度。

二、防止重复

利用redis分布式锁

用分布式锁，是为了防刷、防止同一个用户同一秒里面把购物车里的商品进行多次结算，防止前端代码出问题触发两次。
利用Jedis客户端编写分布式锁

  String result = jedis.set(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime);

lockKey是redis的Key，为用户id+商品id+商品数量组成，这样同一秒中只能有一次处理逻辑。
requestId是redis的value，实际是当前线程id，表示有一条线程占用。

大家要注意这种分布式锁写法，是同时设定超时时间的。有些分布式锁的文章可能是比较旧版的redis不支持同时设置超时时间，他就一条语句先设置key value，另一条语句后设置超时时间。所以大家留意一下。

三、扣减库存

安全扣减库存方案有很多说法，列一下几个方案和我推荐的方案。

方案一：分布式锁

有的文章会用redis分布式锁来做保证扣库存数量准确的环节，让点击结算时，后端逻辑会查询库存和扣库存的update语句同时只有一条线程能够执行，以商品id为分布式锁的key，锁一个商品。但是这样，其他购买相同商品的用户将会进行等待。

• 优点：这样做虽然安全
• 缺点：但是失去的是性能问题。

方案二：分布式锁+分段缓存

也有文章会说借鉴ConcurrenthashMap，分段锁的机制，把100个商品，分在3个段上，key为分段名字，value为库存数量。用户下单时对用户id进行%3计算，看落在哪个redis的key上，就去取哪个。

如key1=product-01,value1=33;key2=product-02,value2=33;key3=product-03,value3=33;

其实会有几个问题：

• 一个是用户想买34件的时候，要去两个片查
• 一个片上卖完了为0，又要去另外一个片查
• 取余方式计算每一片数量，除不尽时，让最后一片补，如100/3=33.33。

缺点：

• 方案复杂
• 有遗留问题

方案三： redis的lpush rpop

redis队列的lpush、rpop都是只能每次进出一个，对于购买多个数量的情况下不适用，只适用于秒杀情况购买一个的场景、或者抢红包的场景，所以觉得不是很通用。

备注：这个抢红包场景以后再分享。

方案四：推荐使用redis原子操作+sql乐观锁

利用Redis increment 的原子操作，保证库存数安全

1. 先查询redis中是否有库存信息，如果没有就去数据库查，这样就可以减少访问数据库的次数。

获取到后把数值填入redis，以商品id为key，数量为value。
注意要设置序列化方式为StringRedisSerializer，不然不能把value做加减操作。
还需要设置redis对应这个key的超时时间，以防所有商品库存数据都在redis中。

1. 比较下单数量的大小，如果够就做后续逻辑。
2. 执行redis客户端的increment，参数为负数，则做减法。因为redis是单线程处理，并且因为increment让key对应的value 减少后返回的是修改后的值。

有的人会不做第一步查询直接减，其实这样不太好，因为当库存为1时，很多做减3，或者减30情况，其实都是不够，这样就白减。

1. 扣减数据库的库存，这个时候就不需要再select查询，直接乐观锁update，把库存字段值减1 。
2. 做完扣库存就在订单系统做下单。

样例场景：

1. 假设两个用户在第一步查询得到库存等于10，A用户走到第二步扣10件，同时一秒内B用户走到第二部扣3件。
2. 因为redis单线程处理，若A用户线程先执行redis语句，那么现在库存等于0，B就只能失败，就不会出更新数据库了。

    public void order(OrderReq req) {
        String key = "product:" + req.getProductId();
        // 第一步：先检查 库存是否充足
        Integer num = (Integer) redisTemplate.get(key);
          if (num == null){
          // 去查数据库的数据
          // 并且把数据库的库存set进redis，注意使用NX参数表示只有当没有redis中没有这个key的时候才set库存数量到redis
          //注意要设置序列化方式为StringRedisSerializer，不然不能把value做加减操作
          // 同时设置超时时间，因为不能让redis存着所有商品的库存数，以免占用内存。
           if (count >=0) {
            //设置有效期十分钟
            redisTemplate.expire(key, 60*10+随机数防止雪崩, TimeUnit.SECONDS);
        }
          // 减少经常访问数据库，因为磁盘比内存访问速度要慢
        }
        if (num < req.getNum()) {
            logger.info("库存不足");
        }
        // 第二步：减少库存
        long value = redisTemplate.increment(key, -req.getNum().longValue());
        // 库存充足
        if (value >= 0) {
            logger.info("成功购买");
            // update 数据库中商品库存和订单系统下单，单的状态未待支付
            // 分开两个系统处理时，可以用LCN做分布式事务，但是也是有概率会订单系统的网络超时
            // 也可以使用最终一致性的方式，更新库存成功后，发送mq，等待订单创建生成回调。
            boolean res= updateProduct(req);
              if (res)
                createOrder(req);
        } else {
            // 减了后小小于0 ，如两个人同时买这个商品，导致A人第一步时看到还有10个库存，但是B人买9个先处理完逻辑，
            // 导致B人的线程10-9=1, A人的线程1-10=-9，则现在需要增加刚刚减去的库存，让别人可以买1个
            redisTemplate.increment(key, req.getNum().longValue());
            logger.info("恢复redis库存");
        }
    }

update使用乐观锁

updateProduct方法中执行的sql如下：

update Product set count = count - #{购买数量} where id = #{id} and count - #{购买数量} >= 0;

虽然redis已经防止了超卖，但是数据库层面，为了也要防止超卖，以防redis崩溃时无法使用或者不需要redis处理时，则用乐观锁，因为不一定全部商品都用redis。

利用sql每条单条语句都是有事务的，所以两条sql同时执行，也就只会有其中一条sql先执行成功，另外一条后执行，也如上文提及到的场景一样。

四、LUA脚本保持库存原子性

其实用方案四的时候，扣减redis的库存时，最好用lua脚本处理，因为如果剩余1个时，用户买100个，这个时候按照方案四，其实会先把key increase -100就会变负99。

所以用lua脚本先查询数量剩余多少，是否够减100后，再去减100。

替换“库存不足”那个判断到incre的那几行代码，没在这里详细描述。

简单说一下分布式事务：

分开两个系统处理库存和订单时，这个时候可以用LCN框架做分布式事务，但是因为是http请求的，也是有概率会订单系统的网络超时，导致未返回结果。

其实也可以使用最终一致性的方式，数据表记录一条交互流水记录，更新库存成功后，更新这个交互流水记录的库存操作字段为已处理，订单处理字段为处理中，然后发送mq，等待订单创建生成回调。也要做定时任务做主动查询订单系统的结果，以防没有结果回来。

方案优势

• 不需要频繁访问数据库商品库存还有多少
• 不阻塞其他用户
• 安全扣减库存量
• 内存访问库存数量，减少数据库交互

高并发额外优化

• 用户访问下单是，前端ui可以让用户触发结算后，把按钮置灰色，防止重复触发。
• 可以按照库存数量来选定是否要用redis，因为如果库存数量少，或者说最近下单次数少的商品，就不用放redis，因为少人看和买的情况下，不必放redis导致占用内存。
• 如果到时间点抢购时，可以使用mq队列形式，用户触发购买商品后，进入队列，让用户的页面一直在转圈圈，等轮到他买的时候再进入结算页面，结算页面的后续流程和本文一致。