mysql--乐观锁与悲观锁

先看下之前关于mysql锁的介绍https://blog.csdn.net/zhang09090606/article/details/117105987

一、简介：

从之前的文章中我们了解到mysql锁按使用方式可以分为乐观锁和悲观锁，也不仅仅是mysql几乎所有涉及锁的地方都分为乐观锁和悲观锁，比如java的lock和cas、synchronized的锁升级、redis的watch乐观锁和Lua脚本实现悲观锁等等，下面将会详细介绍下mysql的乐观锁与悲观锁

二、悲观锁

悲观锁(Pessimistic Locking)，悲观锁是指在数据处理过程，使数据处于锁定状态，一般使用数据库的锁机制实现。

1.使用前提：

mysql使用悲观锁的前提必须要关闭自动提交

set autocommit=0

2.使用场景：

商品出售的场景

一般我们都会走以下三个流程

（1）查库存是否还有剩余

（2）如果满足新增订单并且修改库存

（3）如果不满足直接退出

这三个流程明显不是原子性的，如果并发就会出现超卖的情况，如果我们打算仅使用mysql去保证不超卖就可以将其封装成一个事务解决方案如下

3.悲观锁加锁方式

select...for update是MySQL提供的实现悲观锁的方式。例如select x from items where id=100 for update表示此时在items表中，id为100的那条数据就被我们锁定了，其他事务必须等本次事务提交之后才能执行。这样我们可以保证当前的数据不会被其它事务修改。

4.存在问题

（1）select...for update语句执行中所有扫描过的行都会被锁上，因此一定要确保走索引不然会导致全表被锁上

（2）因为是采用的数据库的锁机制所以性能是很低的，在一些量级特别恐怖的场景这种解决方案是不能接受的

三、乐观锁

乐观锁相对悲观锁而言，它认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回错误信息，让用户决定如何去做。接下来我们看一下乐观锁在数据表和缓存中的实现。

1.流程

 2.具体实现

我们采用version版本号字段或者时间戳字段来实现，在更新提交的时候检查当前数据库中数据的时间戳和自己更新前取到的时间戳、version进行对比，如果一致则OK，否则就是版本冲突。

在上诉流程中

步骤一获取版本号，步骤二修改库存是，加上判断条件版本号要和之前的版本号一直才可以修改成功，然后配合轮询就可以实现乐观锁

// 仍挑选以库存数作为乐观锁
//step1: 查询出商品信息
select (inventory) from items where id=100;
//step2: 根据商品信息生成订单
insert into orders(id,item_id) values(null,100);
//step3: 修改商品的库存
update items set inventory=inventory-1 where id=100 and inventory-1>0;

据说很多大厂秒杀场景就用的这条sql，因为想让库存到0是一件很不容易触发的情况，大多数情况还是有库存的，修改时通过cas的思想比较并替换保证了不超卖