Mysql分布式锁（三）悲观锁实现并发

在前面的方法中，一条sql语句中仍然存在着很多问题，于是我们可以用悲观锁来代替解决。 假设我们不用一条sql，仍然用先查询，判断，最后更新来实现业务。

悲观锁 select…for update

1. 不加悲观锁

1) 两个机器连接mysql

目前数据库数据如下

2）机器1查询1001

3）机器2更新1001

更新成功，此时机器1中查询到的数据，明显就是不对的。 如何解决呢？

2. 加悲观锁

1) 机器1查询1001 select …for update

一定要先开启事务

begin; select count from db_stock where product_code = ‘1001’ for update;

2) 机器2尝试更新1001

阻塞住了

3) 机器1commit，机器2更新操作才完成

很显然，阻塞了20秒。

悲观锁运用到项目中

1. 修改业务代码

StockMapper

@Mapper
public interface StockMapper extends BaseMapper<Stock> {
          
   

    @Select("select * from db_stock where product_code = #{productCode} for update ")
    List<Stock> selectCount(String productCode);
}

StockService

@Service
public class StockService {
          
   

    @Autowired
    private StockMapper stockMapper;

    @Transactional
    public void deduct() {
          
   
        // 1。 查询库存
        List<Stock> list = stockMapper.selectCount("1001");
        // 2。 判断条件是否满足
        if (!CollectionUtils.isEmpty(list)) {
          
   
            // 假设就拿第一个北京仓的
            Stock stock = list.get(0);
            if (stock != null && stock.getCount() > 0) {
          
   
                // 3。 更新库存
                stock.setCount(stock.getCount() - 1);
                stockMapper.updateById(stock);
                System.out.println("当前库存" + stock.getCount());
            }
        }
    }
}

之前这样的业务逻辑，并发测试是有问题的，现在替换成了悲观锁，并发测试下。

2.Jmeter 测试

无报错，吞吐量才20，太低了

数据库数据成功清0，问题解决。但是比一条sql的吞吐量明显降低。

3. 问题

1） 性能问题

吞吐量明显降低

2）死锁问题

示例： 机器1悲观锁查询id=1

机器2悲观锁查询id=2

机器1悲观锁查询id=2,阻塞住了

机器2悲观锁查询id=1，发生死锁

3）库存操作要统一

如果用select…for update， 那业务中其他查询也要用悲观锁，而不能只用select

因为如果其他查询用的select，那查询的数据还是有可能被其他线程修改，导致并发数据问题。