大家好！我是sum墨，一个一线的底层码农，平时喜爱研究和思考一些技术相关的问题并收拾成文，限于自己水平，假如文章和代码有表述不当之处，还请不吝赐教。

以下是正文！

先看问题

首先上一串代码

public String buy(Long goodsId, Integer goodsNum) {
    //查询产品库存
    Goods goods = goodsMapper.selectById(goodsId);
    //假如当时库存为0，提示产品现已卖光了
    if (goods.getGoodsInventory() <= 0) {
        return "产品现已卖光了！";
    }
    //假如当时购买数量大于库存，提示库存缺乏
    if (goodsNum > goods.getGoodsInventory()) {
        return "库存缺乏！";
    }
    //更新库存
    goods.setGoodsInventory(goods.getGoodsInventory() - goodsNum);
    goodsMapper.updateById(goods);
    return "购买成功！";
}

咱们看一下这串代码，逻辑用流程图表明如下：

从图上看，逻辑仍是很明晰明晰的，而且单测的话，也测验不出来什么bug。可是在秒杀场景下，问题可就大发了，100件产品或许卖出1000单，呈现严重资损，这下就真的需求杀个程序员祭天了。

问题分析

正常情况下，假如恳求是一个一个接着来的话，这串代码也不会有问题，如下图：

不同的时刻不同的恳求，每次拿到的产品库存都是更新过之后的，逻辑是ok的。

那为啥会呈现超卖问题呢？ 首先咱们给这串代码添加一个场景：产品秒杀（非秒杀场景难以复现超卖问题）。秒杀场景的特点如下：

高并发处理：秒杀场景下，或许会有很多的购物者一起涌入体系，因而需求具备高并发处理才干，确保体系能够承受高并发拜访，并供给快速的呼应。

快速呼应：秒杀场景下，因为时刻约束和竞赛激烈，需求体系能够快速呼应购物者的恳求，不然或许会导致购买失利，影响购物者的购物体会。

分布式体系：秒杀场景下，单台服务器扛不住恳求顶峰，分布式体系能够进步体系的容错才干和抗压才干，非常适合秒杀场景。

在这种场景下，恳求不或许是一个接一个这种，而是成千上万个恳求一起打过来，那么就会呈现多个恳求在同一时刻查询库存，如下图：

假如在同一时刻查询产品库存表，那么得到的产品库存也肯定是相同的，判断的逻辑也是相同的。

举个例子，现在产品的库存是10件，恳求1买6件，恳求2买5件，因为两次恳求查询到的库存都是10，肯定是能够卖的。可是真实情况是5+6=11>10，显着有问题！这两笔恳求必定有一笔失利才是对的！

那么，这种问题怎样处理呢？

处理计划

从上面例子来看，问题好像是因为咱们每次拿到的库存都是相同的，才导致库存超卖问题，那是不是只要确保每次拿到的库存都是最新的话，这个问题不就方便的解决了吗！

在说计划前，先把我的测验表结构贴出来：

CREATE TABLE `t_goods` (
  `id` bigint NOT NULL COMMENT '物理主键',
  `goods_name` varchar(64) DEFAULT NULL COMMENT '产品名称',
  `goods_pic` varchar(255) DEFAULT NULL COMMENT '产品图片',
  `goods_desc` varchar(255) DEFAULT NULL COMMENT '产品描绘信息',
  `goods_inventory` int DEFAULT NULL COMMENT '产品库存',
  `goods_price` decimal(10,2) DEFAULT NULL COMMENT '产品价格',
  `create_time` datetime DEFAULT NULL COMMENT '创立时刻',
  `update_time` datetime DEFAULT NULL COMMENT '更新时刻',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

办法一、redis分布式锁

Redisson介绍

官方介绍：Redisson是一个基于Redis的Java驻留内存数据网格（In-Memory Data Grid）。它封装了Redis客户端API，并供给了一个分布式锁、分布式调集、分布式对象、分布式Map等常用的数据结构和服务。Redisson支撑Java 6以上版别和Redis 2.6以上版别，并且采用编解码器和序列化器来支撑任何对象类型。 Redisson还供给了一些高级功能，比如异步API和呼应式流式API。它能够在分布式体系中被用来完成高可用性、高功能、高可扩展性的数据处理。

Redisson运用

引入

<!--运用redisson作为分布式锁-->
<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson</artifactId>
    <version>3.16.8</version>
</dependency>

注入对象

RedissonConfig.java

import org.redisson.Redisson;
import org.redisson.api.RedissonClient;
import org.redisson.config.Config;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
@Configuration
public class RedissonConfig {
    /**
     * 所有对Redisson的运用都是经过RedissonClient对象
     *
     * @return
     */
    @Bean(destroyMethod = "shutdown")
    public RedissonClient redissonClient() {
        // 创立配置 指定redis地址及节点信息
        Config config = new Config();
        config.useSingleServer().setAddress("redis://127.0.0.1:6379").setPassword("123456");
        // 依据config创立出RedissonClient实例
        RedissonClient redissonClient = Redisson.create(config);
        return redissonClient;
    }
}

代码优化

public String buyRedisLock(Long goodsId, Integer goodsNum) {
    RLock lock = redissonClient.getLock("goods_buy");
    try {
        //加分布式锁
        lock.lock();
        //查询产品库存
        Goods goods = goodsMapper.selectById(goodsId);
        //假如当时库存为0，提示产品现已卖光了
        if (goods.getGoodsInventory() <= 0) {
                return "产品现已卖光了！";
        }
        //假如当时购买数量大于库存，提示库存缺乏
        if (goodsNum > goods.getGoodsInventory()) {
                return "库存缺乏！";
        }
        //更新库存
        goods.setGoodsInventory(goods.getGoodsInventory() - goodsNum);
        goodsMapper.updateById(goods);
        return "购买成功！";
    } catch (Exception e) {
        log.error("秒杀失利");
    } finally {
        lock.unlock();
    }
    return "购买失利";
}

加上Redisson分布式锁之后，使得恳求由异步变为同步，让购买操作一个一个进行，处理了库存超卖问题，可是会让用户等候的时刻加长，影响了用户体会。

办法二、MySQL的行锁

行锁介绍

MySQL的行锁是一种针对行级别数据的锁，它能够确定某个表中的某一行数据，以确保在确定期间，其他事务无法修正该行数据，然后确保数据的一致性和完整性。特点如下：

MySQL的行锁只能在InnoDB存储引擎中运用。

行锁需求有索引才干完成，不然会自动确定整张表。

能够经过运用“SELECT … FOR UPDATE”和“SELECT … LOCK IN SHARE MODE”语句来显式地运用行锁。

总之，行锁能够有效地确保数据的一致性和完整性，可是过多的行锁也会导致功能问题，因而在运用行锁时需求慎重考虑，防止呈现功能瓶颈。

那么回到库存超卖这个问题上来，咱们能够在一开始查询产品库存的时分添加一个行锁，完成非常简略，也便是将

 //查询产品库存
Goods goods = goodsMapper.selectById(goodsId);
原始查询SQL
SELECT *
  FROM t_goods
  WHERE id = #{goodsId}
改写为
 SELECT *
  FROM t_goods
  WHERE id = #{goodsId} for update

那么被查询到的这行产品库存信息就会被锁住，其他恳求想要读取这行数据时就需求等候当时恳求结束了，这样就做到了每次查询库存都是最新的。不过同Redisson分布式锁相同，会让用户等候的时刻加长，影响用户体会。

办法三、达观锁

达观锁机制相似java中的cas机制，在查询数据的时分不加锁，只要更新数据的时分才比对数据是否现已发生过改动，没有改动则执行更新操作，现已改动了则进行重试。

产品表添加version字段并初始化数据为0

`version` int(11) DEFAULT NULL COMMENT '版别'

将更新SQL修正如下

update t_goods
set goods_inventory = goods_inventory - #{goodsNum},
     version         = version + 1
where id = #{goodsId}
and version = #{version}

Java代码修正如下

public String buyVersion(Long goodsId, Integer goodsNum) {
    //查询产品库存(该语句运用了行锁)
    Goods goods = goodsMapper.selectById(goodsId);
    //假如当时库存为0，提示产品现已卖光了
    if (goods.getGoodsInventory() <= 0) {
        return "产品现已卖光了！";
    }
    if (goodsMapper.updateInventoryAndVersion(goodsId, goodsNum, goods.getVersion()) > 0) {
      return "购买成功！";
    }
    return "库存缺乏！";
}

经过添加了版别号的控制，在扣减库存的时分在where条件进行版别号的比对。完成查询的是哪一条记载，那么就要求更新的是哪一条记载，在查询到更新的过程中版别号不能变动，不然更新失利。

办法四、where条件和unsigned 非负字段约束

前面的Redisson分布式锁和行锁都是经过每次都拿到最新的库存然后处理超卖问题，那换一种思路：确保在扣除库存的时分，库存必定大于购买量是不是也能够处理这个问题呢？答案是能够的。回到上面的代码：

 //更新库存
goods.setGoodsInventory(goods.getGoodsInventory() - goodsNum);
goodsMapper.updateById(goods);

咱们把库存的扣减写在了代码中，这样肯定是不可的，因为在分布式体系中咱们获取到的库存或许都是相同的，应该把库存的扣减逻辑放到SQL中，即：

 update t_goods
 set goods_inventory = goods_inventory - #{goodsNum}
 where id = #{goodsId}

上面的SQL确保了每次获取的库存都是取数据库的库存，不过咱们还需求加一个判断：确保库存大于购买量，即：

update t_goods
set goods_inventory = goods_inventory - #{goodsNum}
where id = #{goodsId}
AND (goods_inventory - #{goodsNum}) >= 0

那么上面那段Java代码也需修正一下：

public String buySqlUpdate(Long goodsId, Integer goodsNum) {
    //查询产品库存(该语句运用了行锁)
    Goods goods = goodsMapper.queryById(goodsId);
    //假如当时库存为0，提示产品现已卖光了
    if (goods.getGoodsInventory() <= 0) {
        return "产品现已卖光了！";
    }
    //此处需求判断更新操作是否成功
    if (goodsMapper.updateInventory(goodsId, goodsNum) > 0) {
        return "购买成功！";
     }
    return "库存缺乏！";
}

还有一种办法和where条件相同，便是unsigned 非负字段约束，把库存字段设置为unsigned 非负字段类型，那么在扣减时也不会呈现扣成负数的情况。

总结一下

处理计划	长处	缺陷
redis分布式锁	Redis分布式锁能够处理分布式场景下的锁问题，确保多个节点对同一资源的拜访次序和安全性，功能较高。	单点故障问题，假如Redis节点宕机，会导致锁失效。
MySQL的行锁	能够确保事务的隔离性，能够防止并发情况下的数据冲突问题。	功能较低，对数据库的功能影响较大，一起也存在死锁问题。
达观锁	相对于悲观锁，达观锁不会堵塞线程，功能较高。	需求额定的版别控制字段，且在高并发情况下容易呈现并发冲突问题。
where条件和unsigned 非负字段约束	能够经过where条件和unsigned非负字段约束来确保库存不会超卖，简略易完成。	或许存在必定的安全隐患，假如某些操作没有正确约束，仍有或许导致库存超卖问题。一起，假如某些场景需求对库存进行多次更新操作，约束条件或许会导致操作失利，需求再次查询数据，对功能会产生影响。

计划有很多，用法结合实际业务来看，没有最优，只要更优，甚至能够几种计划组合起来处理问题。

全文至此结束，再见！

秒杀系统常见问题—如何避免库存超卖？

先看问题

问题分析

处理计划

办法一、redis分布式锁

Redisson介绍

Redisson运用

引入

注入对象

代码优化

办法二、MySQL的行锁

行锁介绍

办法三、达观锁

产品表添加version字段并初始化数据为0

将更新SQL修正如下

Java代码修正如下

办法四、where条件和unsigned 非负字段约束

总结一下

作者信息

秒杀系统常见问题—如何避免库存超卖？

先看问题

问题分析

处理计划

办法一、redis分布式锁

Redisson介绍

Redisson运用

引入

注入对象

代码优化

办法二、MySQL的行锁

行锁介绍

办法三、达观锁

产品表添加version字段并初始化数据为0

将更新SQL修正如下

Java代码修正如下

办法四、where条件和unsigned 非负字段约束

总结一下

相关文章

十七、app加载流程(一)dyld3

震惊！你还要问别人？在这里大佬都给你整理好了！！JdbcTemplate常用方法

Spring Boot 数据验证

都2023年了还不会封装自定义函数式接口？一文教会你

作者信息