ps做网站的视频王也气质头像

超卖问题解决方式

什么是库存超卖问题？

库存超卖是指多个请求同时减少库存时，库存数量变为负数的情况。例如，某商品库存数量为10，同时有两个请求减少库存数量，假设两个请求同时查询库存数量为1，然后各自减少库存数量，最后库存数量变为-1，这就是超卖问题。

乐观锁和悲观锁的定义

• 悲观锁：
  认为线程安全问题一定会发生，因此在操作数据之前先获取锁，确保线程串行执行。例如Synchronized、Lock都属于悲观锁。

  优点：简单粗暴
  缺点：性能一般

• 乐观锁：
  认为线程安全问题不一定会发生，因此不加锁，只是在更新数据时去判断有没有其它线程对数据做了修改。如果没有修改则认为是安全的，自己才更新数据。如果已经被其它线程修改说明发生了安全问题，此时可以重试或异常。

  优点：性能好
  缺点：存在成功率低的问题

超卖问题解决方式

一、悲观锁

1.jvm单机锁

认为线程问题一定会发生，因此在操作数据库之前先获取锁，确保线程串行执行，例如synchronized关键字和ReentrantLock可重入锁。

2.通过使用mysql的行锁，使用一个sql解决并发访问问题

• 通过sql扣减库存

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="com.ht.atp.plat.mapper.WmsStockMapper"><update id="checkAndReduceStock">update wms_stockset stock_quantity = (stock_quantity - #{reduceStock})where id = 1 and (stock_quantity - #{reduceStock}) >= 0;</update>
</mapper>

3.使用mysql的悲观锁解决

• 使用for update加锁查询库存
  

注意：

需要注意的是，该查询库存和更新库存的操作必须放在同一个本地事务中，否则悲观锁将失效。悲观锁只有在本次操作全部完成事务提交之后才会释放锁。如果不在同一个事务中，锁提前释放去更新库存还是会存在并发的问题。

4. 使用redis分布式锁来解决

• 基于redis实现分布式锁

重要指令：set lock_name unique_value NX PX
解释：
unique_value：表示客户端编码，一定要具有唯一性，在解锁的时候，需要验证value和加锁的一致才允许删除key
解决超时问题：第一个进程加锁释放了，但还未执行业务逻辑，第二个进程就获取了锁
NX：若key不存在就设置成功，若存在就返回true
PX：指定过期时间

• 基于redisson开源框架实现

RLock lock =redisson.getLock("huaweiLock");
//只有一个客户端可以成功加锁
lock.lock(); //执行业务逻辑
检查库存
创建订单
扣减库存
更新redis//释放锁，其他客户端可以尝试加锁
lock.unlock();

redis分布式锁的缺点:

redis分布式锁 锁住的资源是，同一个商品的库存多用户同时下单的时候，会基于分布式锁串行化处理，导致没法同时处理同一个商品的大量下单的请求。

redis分布式锁优化：

• 其实说出来也很简单，相信很多人看过java里的ConcurrentHashMap的源码和底层原理，应该知道里面的核心思路，就是分段加锁！

• Java 8中新增了一个LongAdder类，也是针对Java7以前的AtomicLong进行的优化，解决的是CAS类操作在高并发场景下，使用乐观锁思路，会导致大量线程长时间重复循环。

• LongAdder中也是采用了类似的分段CAS操作，失败则自动迁移到下一个分段进行CAS的思路

• 其实这就是分段加锁。你想，假如你现在iphone有1000个库存，那么你完全可以给拆成20个库存段，要是你愿意，可以在数据库的表里建20个库存字段，比如stock_01，stock_02，类似这样的，也可以在redis之类的地方放20个库存key。

• 总之，就是把你的1000件库存给他拆开，每个库存段是50件库存，比如stock_01对应50件库存，stock_02对应50件库存。
  接着，每秒1000个请求过来了，好！此时其实可以是自己写一个简单的随机算法，每个请求都是随机在20个分段库存里，选择一个进行加锁。

• bingo！这样就好了，同时可以有最多20个下单请求一起执行，每个下单请求锁了一个库存分段，然后在业务逻辑里面，就对数据库或者是Redis中的那个分段库存进行操作即可，包括查库存

• 一旦对某个数据做了分段处理之后，有一个坑大家一定要注意：就是如果某个下单请求，咔嚓加锁，然后发现这个分段库存里的库存不足了，此时咋办？
  这时你得自动释放锁，然后立马换下一个分段库存，再次尝试加锁后尝试处理。这个过程一定要实现。

redis分布式锁优化缺点：
首先，你得对一个数据分段存储，一个库存字段本来好好的，现在要分为20个分段库存字段；
其次，你在每次处理库存的时候，还得自己写随机算法，随机挑选一个分段来处理；
最后，如果某个分段中的数据不足了，你还得自动切换到下一个分段数据去处理

二、乐观锁解决

1.版本号

给商品加上版本号字段，如果查询到就让其version=1,在修改执行的时候，先判断版本号是不是正确的，如果是让其版本号发生变化，并执行扣减，如果不是就说明当前商品已经卖出。

2. CAS法（Compare and Switch or Set）。

CAS流程如下：

• 获取目标内存位置的当前值。
• 检查当前值是否与预期值相等。
• 如果相等，则将新值写入目标内存位置；否则，放弃写入操作，可能是重新读取当前值并重试整个CAS操作。

比如当前的订单系统中，就可以使用查询到的库存作为预期值，修改的时候进行判定，如果是库存和第一次查询到的一样就执行，不一样就取消执行，这样就能够保证原子性

• 代码1：

  boolean success = seckillVoucherService.update().setSql("stock= stock -1") //set stick = stock - 1.eq("voucher_id", voucherId).eq("stock", voucher.getStock()) // where id = ? and stock = ?.update();

这种方法结果测试发现出错率较高。比如同时刻有100个请求，第一个请求成功修改库存，但剩余99个请求在乐观锁判断时都发现数据库的库存数据和原先获取的不一致，导致无法通过，事实上我们在修改数据时只需要判断库存是否大于零即可。

• 代码2：

  boolean success = seckillVoucherService.update().setSql("stock= stock -1") //set stick = stock - 1.eq("voucher_id", voucherId).gt("stock",0).update();