本文探讨了商品购买过程中库存扣减的并发控制问题，涉及悲观锁、乐观锁方法，以及使用Redis进行库存操作的优缺点，强调了并发环境下的数据一致性与幂等性问题。
点击关注公众号，Java 干货及时推送↓
推荐阅读：铜三铁四，怒拿 35K * 14 薪！
在商品购买的过程中，库存的抵扣过程，一般操作如下：
2、根据下单的数量，计算库存是否足够，如果存库不足则抛出库存不足的异常，如果库存足够，则减去扣除的库存得到最新的库存剩余值。
// 根据商品id获取商品剩余库存
select stock_remaing from stock_table where id=${goodsId};
// 操作库存
// 比较库存
if(stock_remaing <quantity){
// 抛出库存不足的异常
}
else{
// 抵扣以后的库存值
int new_stock=stock_remaing - quantity;
}
// 根据商品id设置计算后的库存
update stock_table set stock_remaing =${new_stock} id=${goodsId};如果数据库事务的隔离级别不是串行化（serializable），根据事务的特性，在并发修改的时候，可能会出现写覆盖的问题。
加锁更新存库
为了在事务控制中，防止写覆盖，你会想到使用select for update的方式，将该商品的库存锁住，然后执行余下的操作。
流程如下：
以上，使用悲观锁方式，在分布式服务中，如果并发情况比较高的时候，扣减库存的操作是串行操作，效率很低。最新面试题整理好了，点击Java面试库小程序在线刷题。
在更新的时候，使用（CAS+版本号更新）+重试条件（重试次数或者重试时间限制）乐观锁的方式更新库存。此时，如果，客户A和客户B同时读取到库存剩余100，在更新的时候，有一个操作会失败。
该种方式可以大大提高并发性，也可以保证数据的一致性；通过重试次数和重试时间的条件控制，可以防止过多的重试带来的数据库压力。
推荐一个 Spring Boot 基础教程及实战示例：
https://github.com/javastacks/spring-boot-best-practice
在抵扣库存的时候，有的人提议不执行select，计算，set三段式的操作，直接扣减的方式，并且对于扣减到小于零的情况作了判断。伪代码如下：
update stock_table set remaing_stock=remaing_stock-${quantity}
where id =商品id
and remaing_stock>${quantity};答案是可以使用redis的事务性扣减余额，但在CAS机制上比mysql没有优势，高性能是因为其内存存储的原因，带来的副作用是数据有丢失风险。
原文链接：https://blog.csdn.net/new_com/article/details/105568124
推荐阅读：
关注公众号学习最主流的 Java 技术↓
扫一扫
29万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
