聊聊乐观锁与悲观锁

2024年 5月 17日 73.3k 0

悲观锁

在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”)。

悲观锁之所以被称为悲观,是因为这是一种对数据的修改抱有悲观态度的并发控制方式。一般来说,我们认为数据被并发修改的概率较大,因此在修改之前先加锁。

悲观并发控制实际上是一种保守的策略,即“先取锁再访问”,它为数据处理的安全性提供了保证。

聊聊乐观锁与悲观锁-1图片

在效率方面,处理加锁机制会导致数据库产生额外的开销,增加了产生死锁的风险。此外,悲观锁还可能降低并行性,因为如果一个事务锁定了某行数据,其他事务就必须等待该事务完成才能处理该行数据。

乐观锁

乐观锁(Optimistic Locking)是相对悲观锁而言的。乐观锁假设数据在一般情况下不会发生冲突,因此在数据提交更新时才会实际检查数据是否冲突。如果发现冲突,则会向用户返回错误信息,让用户决定如何处理。

与悲观锁相比,乐观锁在处理数据库时并不会使用数据库提供的锁机制。一般来说,乐观锁的实现方式是通过记录数据的版本信息。

聊聊乐观锁与悲观锁-2图片

乐观并发控制相信事务之间的数据竞争(data race)的概率较小,因此尽可能直接进行操作,直到提交时才对数据进行检查和锁定。这样做不会产生任何锁或死锁。

如何选择

在乐观锁与悲观锁的选择上面,主要看下两者的区别以及适用场景就可以了。

1. 乐观锁并未真正加锁,效率高。适用于读操作频繁,写操作相对较少的场景。一旦锁的粒度掌握不好,更新失败的概率就会比较高,容易发生业务失败。

2. 悲观锁依赖数据库锁,效率低。更新失败的概率比较低。适用于写操作较为频繁,且并发写入的概率较高的场景。

根据以上区别和场景特点,可以针对具体业务需求选择合适的并发控制策略。当然最多的场景其实当属于高并发场景如何选择。

相关文章

JavaScript2024新功能:Object.groupBy、正则表达式v标志
PHP trim 函数对多字节字符的使用和限制
新函数 json_validate() 、randomizer 类扩展…20 个PHP 8.3 新特性全面解析
使用HTMX为WordPress增效:如何在不使用复杂框架的情况下增强平台功能
为React 19做准备:WordPress 6.6用户指南
如何删除WordPress中的所有评论

发布评论