这里以一个最基础的库存问题引入:在高并发下下单会造成库存数据异常情况。
数据表:就一个最基础的库存表和一个基础的数据。
2. 新建SpringBoot2.7.3项目并引入相关依赖:
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
</dependency>
<dependency>
<groupId>com.baomidou</groupId>
<artifactId>mybatis-plus-boot-starter</artifactId>
<version>3.5.1</version>
</dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
- mapper
public interface StockMapper extends BaseMapper<Stock> {
}
- service
@Service
public class StockServiceImpl implements StockService {
@Resource
private StockMapper stockMapper;
@Override
public Integer deStock() {
Stock stock = stockMapper.selectOne(new QueryWrapper<Stock>()
.eq("product_code", "1001"));
if (!Objects.isNull(stock)
&& stock.getCount() > 0){
stock.setCount(stock.getCount() -1);
stockMapper.updateById(stock);
}
return stockMapper.selectById(stock.getId()).getCount();
}
}
2.controller
@RestController
@RequestMapping("/stock")
public class StockController {
@Resource
private StockService stockService;
@GetMapping
public String deStock(){
return "库存剩余:" stockService.deStock();
}
}
- 使用十个线程各发送十各请求,也就是共100各请求,这里设置数据中也刚好有100库存。
- 请求之后可以发现:请求的数量与数据库中的库存剩余对应不上,这个值应该处于于0 - 90 之间,每个用户至少有一个请求会进去。
这里直接不测试了,肯定可以解决。
修改service减库存方法:
synchronized
@Override
public synchronized Integer deStock() {
Stock stock = stockMapper.selectOne(new QueryWrapper<Stock>()
.eq("product_code", "1001"));
if (!Objects.isNull(stock)
&& stock.getCount() > 0){
stock.setCount(stock.getCount() -1);
stockMapper.updateById(stock);
}
return stockMapper.selectById(stock.getId()).getCount();
}
ReentrantLock 显示锁
@Override
public Integer deStock() {
ReentrantLock reentrantLock = new ReentrantLock();
try {
reentrantLock.lock();
Stock stock = stockMapper.selectOne(new QueryWrapper<Stock>()
.eq("product_code", "1001"));
if (!Objects.isNull(stock)
&& stock.getCount() > 0){
stock.setCount(stock.getCount() -1);
stockMapper.updateById(stock);
}
return stockMapper.selectById(stock.getId()).getCount();
}finally {
reentrantLock.unlock();
}
}
- 只有是单例的 stockService 对象下才能保证锁进行成功,在多例情况下每个对象都拥有自己的锁,不需要等待其他线程释放锁就可以执行。
- 在开启spring事务的情况下锁也可能(有一定几率)失效:由于spring的锁是使用AOP的方式来进行增强,如果同时A、B两个用户分别发送两个请求事务也会开启两个,但是由于只能一个用户(线程)才能够获得锁,完成之后才会释放锁;此时A用户的事务并没有提交,但是B用户已经可以获取当前方法的锁,那么就会造成一个数据不一致的问题,B获取的库存是A提交前的数量。如图:
- 当然可以通过设置Spring事务中的隔离级别为读未提交来解决,但这种隔离级别就完全不满足系统需求了。
- 集群模式下:在不同的服务中的 stockService 肯定也不是一个相同的对象,存在与第一中失效方式相似的问题。
使用MySQL中自带的锁去解决:MySQL在执行更、删、改操作时会自动对当前语句加锁,也就是说我们只要能够使用一条sql来实现当前功能就可以避免数据问题。
- 新增mapper接口方法:
@Update("update db_stock set count = count - #{count} "
"where product_code = #{productCode} and count >= #{count}")
Integer deduct(@Param("productCode") String productCode, @Param("count") Integer count);
修改service实现类方法:
@Override
public Integer deStock() {
return stockMapper.deduct("1001", 1);
}
- 使用Jmeter来测试,可以发现不会出现数据异常问题。
- 解决:很明显的可以看出一条sql中携带的锁可以完美的解决上方JVM锁失效的问题,但是真的那么?
- 发现问题:一条sql无法实现在复杂情况下的操作,例如:如果一条商品code有多个仓库,就无法实现了。同样的无法记录库存在进行下单前后的状态变化。锁的粒度:通过分析可以看出,当前sql是一个表级锁,即当前sql在事务为提交之前,其他的io操作都无法执行。
- 使用 select ... for update ,可以对当前查询出的数据加上行级锁,即其他事务无法对已经查询出的数据进行修改删除等操作。
- 但是想要改为行级锁就必须满足以下要求:
- 查询或者更新条件必须是索引字段;
- 查询或者更新条件必须是一个具体值(不能使索引失效);
- 新增 mapper 中方法:
@Select("select * from db_stock where product_code = #{productCode} for update")
List<Stock> selectStockForUpdate(String productCode);
改造 service 中方法:
@Transactional
@Override
public Integer deStock() {
List<Stock> stocks = stockMapper.selectStockForUpdate("1001");
if (Objects.isNull(stocks) || stocks.isEmpty()){
return -1;
}
// 假设存在多仓库情况,默认扣减第一个仓库
Stock stock = stocks.get(0);
if (!Objects.isNull(stock) && stock.getCount() >= 1){
stock.setCount(stock.getCount() - 1);
}
return stockMapper.updateById(stock);
}
- 使用Jmeter测试,可以看出悲观锁也可以实现数据异常的问题。
- 优缺点:效率比JVM锁高,但是比一条sql低;可能存在死锁问题:需要保证对多条数据加锁时顺序一致;库存操作要统一:要么都 select ... for update ,要么都 select ,一个有锁一个没有锁指定会出现数据冲突问题。
乐观锁:默认对IO属性操作不加锁,在执行完毕对数据中的版本号或者其他属性进行判断,确定当前数据执行前后是否被其他的事务更改。也就是CAS思想。
CAS:Compare and Swap,比较并交换,其实就是有用一个属性,在更新后判断当前属性是否有变化,有变化就放弃更改,无变化就更改。
- 更改成功
- 放弃更改
- 修改数据库表:新增版本号字段。每次更改时将version进行加一。
修改 service 方法
@Override
public Integer deStock() {
List<Stock> stocks = stockMapper.selectList(
new QueryWrapper<Stock>()
.eq("product_code", "1001"));
if (Objects.isNull(stocks) || stocks.isEmpty()){
return -1;
}
// 假设存在多仓库情况,默认扣减第一个仓库
Stock stock = stocks.get(0);
Integer version = 0;
if (!Objects.isNull(stock) && stock.getCount() >= 1){
version = stock.getVersion();
stock.setCount(stock.getCount() - 1);
stock.setVersion(version 1);
}
QueryWrapper<Stock> queryWrapper = new QueryWrapper<>();
queryWrapper
.eq("id", stock.getId())
.eq("version", version);
int update = stockMapper.update(stock, queryWrapper);
// 更新失败递归重试
if (update == 0){
try {
// 避免一直重试导致栈内存溢出
Thread.sleep(20);
} catch (InterruptedException e) {
e.printStackTrace();
}
return deStock();
}
return update;
}
- 通过Jmeter今天压力测试,发现可以满足数据一致的问题。
- 问题分析:
version
- 性能:一条sql锁>悲观锁>JVM锁>乐观锁。
- 在业务场景允许的情况下肯定优先选择一条更新sql自带的 默认锁 啊。
- 如果是多读少写,争抢不是很激烈的情况下优先选择 乐观锁 。
- 如果写入的并发量比较高,而且经常出现锁冲突,为了避免出现锁冲突而进行自旋的情况越来越多,优先选择 悲观锁 。