目录
MySQL乐观锁在并发扣减商品库存方面的应用
1、经典案例说明：银行转账
背景：在银行上班的两操作员同时操作同一账户。
问题举例：A、B 两个操作员同时读取一个账户余额为1000元的账户，A操作员为该账户增加100元，同时B操作员为该账户扣减50元，A操作员先提交，B操作员后提交。最后，经过A和B两个操作员的一番操作后，客户的实际账户余额为 1000-50=950元。但是，本该为 1000+100-50=1050。这就是典型的并发问题。
乐观锁机制：乐观锁机制在一定程度上解决了这个问题。乐观锁，大多数是基于数据版本记录机制（version）来实现的。那么，什么是数据版本呢？数据版本，就是为 数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。
具体实现过程是：在业务中，读出业务数据时，会将此业务数据对应的版本号一同读出，之后对业务数据做更新时，会同时对此版本号 加1。此时，将本次业务中一开始读出的业务数据所对应的版本号与数据库表中对应记录的当前版本号进行比对，如果提交的业务数据版本号大于数据库表当前版本号，则予以更新，否则，则认为是过期数据。
案例解释：对于上面修改客户帐户余额的例子而言，假设数据库中帐户信息表中有一个version字段，当前值为1；而当前帐户余额字段 balance 为1000元。假设，操作员A先更新完，操作员B后更新。
（1）A操作员此时将其读出（version=1），并将其帐户余额增加100（1000+100=1100）。
（2）在A操作员的操作未提交之前，B操作员也读入此用户信息（version=1），并从其帐户余额中扣除50（1000-50=950）。
（3）此时，A操作员完成了修改工作，一方面是将数据版本号加一（version=2），另一方面是连同帐户余额增加100（balance=1100=1000+100），并且提交至数据库更新，此时，由于提交数据版本大于数据库记录当前版本，数据可以被更新，数据库记录version更新为2。
（4）B操作员也完成了操作，一方面是将数据版本号加一（version=2），另一方面是连同帐户余额扣减50（balance=950=1000-50），但此时，当B操作员提交更改时，在比对提交数据版本和数据库记录版本时发现，B操作员的提交数据版本号为2，数据库记录当前版本号也为2，不满足 “提交版本必须大于记录当前版本才能执行更新” 的乐观锁策略，因此，B操作员的提交被驳回。
（5）这样，就避免了B操作员用基于version=1的旧数据（或者说已失效数据）修改的结果覆盖A操作员的操作结果的可能。
2、乐观锁介绍：详解内容见这里
相对于悲观锁而言，乐观锁（Optimistic Locking）假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则会返回用户错误的信息，让用户决定如何去做。
实现乐观锁一般有以下2种方式：
（1）使用版本号实现乐观锁：数据版本机制，或者时间戳机制。
（2）使用条件限制实现乐观锁。
2.1 使用版本号实现乐观锁：数据版本机制，或者时间戳机制
（1）方式1：使用数据版本机制（Version）来实现，这是乐观锁最常用的一种实现方式。
实现机制：何谓数据版本？即为数据增加一个版本标识，一般是通过为数据库表增加一个 “version” 字段来实现。当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加一。当提交更新的时候，判断数据库表对应记录的当前版本号与当前业务中第一次取出来的version值进行比对，如果数据库表当前版本号与当前业务中第一次取出来的version值相等，则予以更新；否则，认为是过期数据。如图：
如图所示，如果A和B的更新操作顺序执行，则数据的版本号（version）依次递增，不会产生冲突。但是，如果有不同的业务操作对同一版本号的数据进行修改，那么，先提交的操作（图中B）会把数据version更新为2，当A在B提交之后更新时会发现数据的version已经被修改了，那么A的更新操作将会失败。
（2）方式2：时间戳机制。
时间戳机制，同样是在需要乐观锁控制的数据库表中增加一个字段 timestamp，字段类型使用时间戳（timestamp）, 和上面的version类似，也是在提交更新的时候检查当前数据库中数据的时间戳和自己更新前第一次取到的时间戳进行对比，如果一致则OK，否则，就是版本冲突。
2.2 使用条件限制实现乐观锁
使用条件限制实现乐观锁，这个适用于在更新时做数据安全校验，适合商品库存模型、扣份额、回滚份额等，性能更高。
3、解决方案1：使用版本号version实现乐观锁
3.1 下单时，商品信息表Goods的变化过程
商品Goods表中有一个字段status，status为1 代表商品未被下单，status为2 代表商品已经被下单。那么，对某个商品下单时必须确保该商品的status为1。假设，商品的id为1。下单操作包括如下三个步骤：
（1）查询出商品信息：
select name,status,version from Goods where id=#{id}（2）根据商品信息生成订单：
xxx（3）然后，修改商品信息表中的status=2：
update Goods set status=2,version=version+1 where id=#{id} and version=#{version};3.2 使用version版本号方案实现乐观锁
为使用乐观锁机制修改Goods表，为Goods表增加一个version字段，数据默认version值为1。
Goods表的初始数据如下：
mysql> select * from Goods;
+----+--------+------+---------+
| id | status | name | version |
+----+--------+------+---------+
| 1 | 1 | 道具 | 1 |
| 2 | 2 | 装备 | 2 |
+----+--------+------+---------+
2 rows in set
对于乐观锁的实现，使用MyBatis来进行实践，具体如下：
3.2.1 Goods实体类：
public class Goods implements Serializable {
/**
* serialVersionUID：序列化ID
*/
private static final long serialVersionUID = 5803791908148880587L;
/**
* id:主键id
*/
private int id;
/**
* status：商品状态：1-未下单；2-已下单
*/
private int status;
/**
* name：商品名称
*/
private String name;
/**
* version：商品数据版本号
*/
private int version;
@Override
public String toString(){
return "good id:"+id+", goods status:"+status+", goods name:"+name+
", goods version:"+version;
}
//setter and getter
}3.2.2 GoodsDao层：
/**
* updateGoodsUseCAS:使用CAS(Compare and set)更新商品信息
* @param goods 商品对象
* @return 影响的行数
*/
int updateGoodsUseCAS(Goods goods);3.2.3 XML层：mapper.xml：
<update id="updateGoodsUseCAS" parameterType="Goods">
<![CDATA[
update goods
set status=#{status},name=#{name},version=version+1
where id=#{id} and version=#{version}
]]>
</update>3.2.4 GoodsDaoTest 测试类：
@Test
public void goodsDaoTest(){
int goodsId = 1;
//根据相同的id查询出商品信息，赋给2个对象
Goods goods1 = this.goodsDao.getGoodsById(goodsId);
Goods goods2 = this.goodsDao.getGoodsById(goodsId);
//打印当前商品信息
System.out.println(goods1);
System.out.println(goods2);
//更新商品信息1
goods1.setStatus(2);//修改status为2
int updateResult1 = this.goodsDao.updateGoodsUseCAS(goods1);
System.out.println("修改商品信息1"+(updateResult1==1?"成功":"失败"));
//更新商品信息2
goods1.setStatus(2);//修改status为2
int updateResult2 = this.goodsDao.updateGoodsUseCAS(goods2);
System.out.println("修改商品信息2"+(updateResult2==1?"成功":"失败"));
}3.2.5 输出测试结果：
good id:1, goods status:1, goods name:道具, goods version:1
good id:1, goods status:1, goods name:道具, goods version:1
修改商品信息1成功
修改商品信息2失败3.3 测试说明：
在GoodsDaoTest测试方法中，同时查出同一个版本的数据，赋给不同的goods对象，然后先修改good1对象然后执行更新操作，执行成功。然后修改goods2对象，执行更新操作时提示操作失败。此时goods表中数据如下：
mysql> select * from Goods;
+----+--------+------+---------+
| id | status | name | version |
+----+--------+------+---------+
| 1 | 2 | 道具 | 2 |
| 2 | 2 | 装备 | 2 |
+----+--------+------+---------+
2 rows in set
可以看到 id为1的数据version 已经在第一次更新时修改为2了。所以，更新good2时的update where条件已经不匹配了，所以更新不会成功。这样就用版本号实现了乐观锁。
其实这种版本号的方法并不是适用于所有的乐观锁场景。举个例子，当电商抢购活动时，大量并发进入时，如果仅仅使用版本号或者时间戳，就会出现大量的用户查询出库存存在，但是却在扣减库存时失败了，而这个时候库存是确实存在的。想象一下，版本号每次只会有一个用户扣减成功，不可避免的人为造成其他的很多用户扣减失败。这个时候，就需要第二种场景的乐观锁实现方案了。
4、解决方案2：使用条件限制实现乐观锁
同样以上述案例为例。将Goods表结构修改如下：
status表示产品状态：1-在售；2-暂停出售。quantity表示产品库存。
mysql> select * from Goods;
+----+--------+------+---------+
| id | status | name | quantity|
+----+--------+------+---------+
| 1 | 1 | 道具 | 10 |
| 2 | 2 | 装备 | 10 |
+----+--------+------+---------+
rows in set
mysql>更新库存操作如下：
update Goods set quantity = quantity - #{buyQuantity}
where id = #{id}
and quantity - #{buyQuantity} >= 0
and status = 1说明：
quantity - #{buyQuantity}>=0这个条件限制 适合于不使用版本号、只在更新时做数据安全校验的业务场景，适合库存模型、扣份额、回滚份额等，性能更高。
注意：乐观锁的更新操作，最好用主键或者唯一索引来更新，这样使用的是行锁，否则更新时会锁表，造成事实上的串行执行。
99、参考
（1）https://blog.csdn.net/cmm0401/article/details/115816459
（2）https://blog.csdn.net/cmm0401/article/details/115655095
（3）https://www.jianshu.com/p/efe85c5b4d62
（4）
3112
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
