聊聊乐观锁与悲观锁

悲观锁

在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. 1. 乐观锁并未真正加锁，效率高。适用于读操作频繁，写操作相对较少的场景。一旦锁的粒度掌握不好，更新失败的概率就会比较高，容易发生业务失败。
2. 2. 悲观锁依赖数据库锁，效率低。更新失败的概率比较低。适用于写操作较为频繁，且并发写入的概率较高的场景。

根据以上区别和场景特点，可以针对具体业务需求选择合适的并发控制策略。当然最多的场景其实当属于高并发场景如何选择。感兴趣的小伙伴可以留言。mark一下，后续聊一聊高并发场景中，乐观锁和悲观锁哪个更合适。

好了，本章节到此告一段落。希望对你有所帮助，祝学习顺利。