悲观锁
在MySQL中,悲观锁依赖数据库提供的锁机制来实现。在InnoDB引擎中,使用悲观锁需要先关闭MySQL数据库的自动提交属性,然后通过select ... for update来进行加锁。
在数据库中,悲观锁的流程如下:
• 在对记录进行修改前,先尝试为该记录加上排他锁(exclusive lock)。
• 如果加锁失败,说明该记录正在被修改,此时当前查询可能需要等待或抛出异常,具体响应方式由开发者根据实际需求决定。
• 如果成功加锁,则可以对记录进行修改,事务完成后锁将被释放。
• 其间若有其他操作试图对该记录进行修改或加排他锁,则会等待当前锁的释放或直接抛出异常。
我们以电商平台下单过程中扣减库存的需求为例,说明如何使用悲观锁:
-- 0.开始事务
begin;
-- 1.查询出商品信息
SELECT stock FROM products WHERE product_id = 12345 FOR UPDATE;
-- 2.修改商品stock为2
update products set stock=2 where product_id = 12345;
-- 3.提交事务
commit;
在对id=1的记录进行修改前,先通过FOR UPDATE的方式加锁,然后再进行修改。这就是典型的悲观锁策略。
如果上述修改库存的代码发生并发,同一时间只有一个线程可以开启事务并获得id=1的锁,其他事务必须等本次事务提交之后才能执行。这样,我们可以保证当前的数据不会被其他事务修改。
上面提到,使用SELECT ... FOR UPDATE会将数据锁住,不过我们需要注意一些锁的级别。MySQL InnoDB默认使用行级锁。行级锁都是基于索引的,如果一条SQL语句未使用索引,优化器在选择时,若发现锁表可能性能更好,有可能会直接锁表。
上面这个点之前也有在文章提到过:
日活3kw的实际库存业务场景中的超卖到底怎么解决的
感兴趣的可以参考阅读一下,希望对你有所帮助
乐观锁
MySQL中的乐观锁主要通过CAS(Compare and Swap)的机制来实现,通常使用版本号(version)来实现。
CAS是一种乐观锁技术,当多个线程尝试使用CAS同时更新同一个变量时,只有其中一个线程能成功更新变量的值,而其他线程都失败。失败的线程并不会被挂起,而是被告知在此次竞争中失败,并可以再次尝试。
以扣减库存为例,通过乐观锁可以实现如下:
-- 查询出商品信息,stock = 3
select stock from products product_id id= 1
-- 根据商品信息生成订单
-- 修改商品stock为2
update products set stock=2 where id=1 and stock = 3;
以上,在更新之前,先查询库存表中当前的库存数(stock),然后在执行更新时,将库存数作为修改条件。提交更新时,对比数据库表记录的当前库存数与第一次查询得到的库存数,若两者相等,则执行更新;否则,视为数据已过期。
题外话
悲观锁
在对数据库中的数据进行修改时,为了避免同时被其他人修改,最好的方法是直接对该数据进行加锁以防止并发。这种在修改数据之前先锁定再修改的方式被称为悲观并发控制(又称“悲观锁”,Pessimistic Concurrency Control,缩写为“PCC”)。
悲观锁之所以被称为悲观,是因为这是一种对数据的修改抱有悲观态度的并发控制方式。一般来说,我们认为数据被并发修改的概率较大,因此在修改之前先加锁。
悲观并发控制实际上是一种保守的策略,即“先取锁再访问”,它为数据处理的安全性提供了保证。
图片
在效率方面,处理加锁机制会导致数据库产生额外的开销,增加了产生死锁的风险。此外,悲观锁还可能降低并行性,因为如果一个事务锁定了某行数据,其他事务就必须等待该事务完成才能处理该行数据。
乐观锁
乐观锁(Optimistic Locking)是相对悲观锁而言的。乐观锁假设数据在一般情况下不会发生冲突,因此在数据提交更新时才会实际检查数据是否冲突。如果发现冲突,则会向用户返回错误信息,让用户决定如何处理。
与悲观锁相比,乐观锁在处理数据库时并不会使用数据库提供的锁机制。一般来说,乐观锁的实现方式是通过记录数据的版本信息。
图片
乐观并发控制相信事务之间的数据竞争(data race)的概率较小,因此尽可能直接进行操作,直到提交时才对数据进行检查和锁定。这样做不会产生任何锁或死锁。
如何选择
在乐观锁与悲观锁的选择上面,主要看下两者的区别以及适用场景就可以了。
1. 乐观锁并未真正加锁,效率高。适用于读操作频繁,写操作相对较少的场景。一旦锁的粒度掌握不好,更新失败的概率就会比较高,容易发生业务失败。
2. 悲观锁依赖数据库锁,效率低。更新失败的概率比较低。适用于写操作较为频繁,且并发写入的概率较高的场景。
根据以上区别和场景特点,可以针对具体业务需求选择合适的并发控制策略。当然最多的场景其实当属于高并发场景如何选择。