MySQL乐观锁在并发扣减商品库存方面的应用

目录

MySQL乐观锁在并发扣减商品库存方面的应用

1、经典案例说明:银行转账

2、乐观锁介绍:详解内容见这里

2.1 使用版本号实现乐观锁:数据版本机制,或者时间戳机制

2.2 使用条件限制实现乐观锁

3、解决方案1:使用版本号version实现乐观锁

3.1 下单时,商品信息表Goods的变化过程

3.2 使用version版本号方案实现乐观锁

3.2.1 Goods实体类:

3.2.2 GoodsDao层:

3.2.3 XML层:mapper.xml:

3.2.4 GoodsDaoTest 测试类:

3.2.5 输出测试结果:

3.3 测试说明:

4、解决方案2:使用条件限制实现乐观锁

99、参考

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)

 

<think>好的,我现在需要给用户介绍一下MySQL乐观锁。首先,我得回忆一下乐观锁的基本概念,确保自己理解正确。乐观锁是一种并发控制机制,和悲观锁不同,它假设事务之间的竞争不激烈,所以在操作数据时不会立即加锁,而是在提交更新时检查是否有冲突。 接下来,我应该考虑用户可能的背景。用户可能在使用MySQL时遇到了并发问题,或者听说过乐观锁但不太清楚具体实现。他们需要了解如何在MySQL应用乐观锁,以及它的适用场景。 首先,要解释乐观锁的核心思想,即通过版本号或时间戳来检测数据是否被修改。然后,具体说明实现方式,比如在表中增加一个version字段,每次更新时检查version是否和读取时一致。这里需要举一个具体的SQL例子,比如UPDATE语句中的WHERE条件包含version的判断,并同时更新version值。 还要对比乐观锁和悲观锁的区别,比如悲观锁使用SELECT ... FOR UPDATE,而乐观锁不锁定数据,依赖应用程序处理冲突。需要提到乐观锁适用于读多写少的场景,冲突较少的情况,而高并发写入可能更适合悲观锁。 另外,用户可能关心实际应用中的注意事项,比如重试机制。当更新失败时,如何处理,比如捕获异常后重新尝试操作。这部分需要给出一些代码示例或者逻辑步骤,帮助用户理解如何实现。 可能还需要提到乐观锁的优点,比如减少锁的开销,提高吞吐量,以及缺点,比如需要处理冲突,增加业务逻辑的复杂度。同时,提醒用户在高并发写的情况下,乐观锁可能导致频繁的重试,影响性能。 最后,总结一下使用场景和实现步骤,确保用户有一个清晰的指导。检查是否有遗漏的关键点,比如版本号的类型,是否必须使用整数,或者时间戳的精度问题。可能还要说明CAS(Compare and Swap)操作就是乐观锁的一种实现方式,增强用户的理解。 现在需要把这些点组织成一个连贯的回答,结构清晰,分点说明,并给出示例,让用户能够一步步理解如何在实际项目中应用乐观锁。同时,语言要简洁明了,避免技术术语过多,必要时用比喻帮助理解。</think>MySQL乐观锁是一种**无锁并发控制机制**,适用于**低冲突、高并发读**的场景。它通过版本号/时间戳实现数据冲突检测,核心思路是**提交更新时验证数据是否被修改**。以下是详细说明: --- ### 一、实现原理 1. **版本号机制** - 表中增加`version`字段(整数类型) - 读取数据时记录当前版本号 - 更新时验证版本号是否未变,并自增版本号 ```sql -- 读取阶段 SELECT id, stock, version FROM product WHERE id=1; -- 假设此时version=3 -- 更新阶段(核心) UPDATE product SET stock = stock - 1, version = version + 1 WHERE id=1 AND version=3; -- 关键:原子性验证版本号 ``` 2. **时间戳机制** - 使用`last_modified`字段记录修改时间 - 更新时验证时间戳是否一致 --- ### 二、与悲观锁对比 | 特性 | 乐观锁 | 悲观锁(SELECT...FOR UPDATE) | |---------------|---------------------------------|-------------------------------------| | 锁机制 | 无物理锁,逻辑冲突检测 | 物理行锁/表锁 | | 性能 | 高吞吐(无锁竞争) | 低吞吐(锁开销) | | 冲突处理 | 需业务层处理重试 | 数据库自动阻塞 | | 适用场景 | 读多写少(电商库存、订单状态) | 写多读少(银行转账) | | 数据一致性 | 最终一致 | 强一致 | --- ### 三、实战注意事项 1. **重试策略** ```python max_retries = 3 for _ in range(max_retries): try: # 1. 查询数据及版本号 data, version = query_data() # 2. 业务计算 new_data = process(data) # 3. 尝试更新 affected = update_data(new_data, version) if affected > 0: break except ConflictError: continue ``` 2. **版本号设计** - 使用`BIGINT UNSIGNED`避免溢出 - 每次修改必须更新版本号 3. **混合使用场景** ```sql -- 结合库存数量双重验证 UPDATE product SET stock = stock - 1, version = version + 1 WHERE id=1 AND version=3 AND stock > 0; ``` --- ### 四、适用场景 1. **秒杀库存扣减** 2. **订单状态变更** 3. **账户余额更新** 4. **多终端数据同步** --- ### 五、优缺点分析 ✅ **优点** - 无锁竞争,系统吞吐量高 - 避免死锁问题 - 实现轻量(仅需添加版本字段) ❌ **缺点** - 高并发写时冲突率高 - 需业务层处理重试逻辑 - 不保证绝对一致性(需最终一致补偿) --- 通过合理使用乐观锁,可以在保证数据一致性的同时显著提升系统并发能力。建议在冲突概率低于20%时优先采用此方案。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值