秒杀场景下用乐观锁解决超卖问题

前言

超卖问题通常出现在多用户并发操作的情况下，即多个用户尝试购买同一件商品，导致商品库存不足或者超卖。解决超卖问题的方法有很多：乐观锁、Redis分布式锁、消息队列等。
为什么用乐观锁不用悲观锁来解决？
因为在秒杀场景下，使用悲观锁太影响程序性能，而且增加了死锁的风险。而乐观锁就可以更好的适应这种场景。
乐观锁与悲观锁

---

对秒杀场景不做高并发处理的结果

数据库中秒杀商品库存位10：

秒杀记录情况：

JMeter模拟高并发：
每秒1000次请求下单秒杀商品：

设置测试的请求路径：

结果：
秒杀商品库存为0：

秒杀记录1000条：

这个结果肯定不是我们想要的，在实战场景下，要做好高并发场景下对库存和订单的限制，坚决抵制超卖问题！

乐观锁实现处理高并发问题

实现思路 ：

1. 在数据库中，每个商品记录可以包含一个版本号（version字段）。
2. 在购买操作之前，检查商品的版本号。如果有其他用户在你之前购买了同一商品，版本号会发生变化。如果版本号不匹配，说明有冲突，应该回滚并返回错误。
3. 如果版本号匹配，才执行购买操作，并更新版本号。

更新商品库存业务层方法：

@Override
    public int reduceInventory(Product product) {
//        return productMapper.updateById(product);
        return productMapper.updateStock(product.getStock(),product.getPid(),product.getVersion());
    }

更新商品库存数据访问层方法：

@Update("update shop_product SET stock= #{stock} ,version = version + 1 WHERE pid = #{pid} and version =#{versoin}")
    int updateStock(@Param("stock") int stock, @Param("pid") int pid,@Param("versoin") int versoin);

在商品服务的减库存方法中，对更新库存的操作做乐观锁设计。

相同场景的模拟测试结果：
商品库存为0：

秒杀记录（下单记录）10条：

通过乐观锁设计，成功解决秒杀场景下的超卖问题！
成功撒花！

---