精华内容
下载资源
问答
  • MySql 乐观锁

    2020-04-27 14:36:14
    转载自:使用mysql乐观锁解决并发问题 案例说明: 银行两操作员同时操作同一账户。 比如A、B操作员同时读取一余额为1000元的账户,A操作员为该账户增加100元,B操作员同时为该账户扣除50元,A先提交,B后提交。最后...

    转载自:使用mysql乐观锁解决并发问题

    案例说明:

    银行两操作员同时操作同一账户。
    比如A、B操作员同时读取一余额为1000元的账户,A操作员为该账户增加100元,B操作员同时为该账户扣除50元,A先提交,B后提交。最后实际账户余额为1000-50=950元,但本该为1000+100-50=1050。这就是典型的并发问题。

    乐观锁机制在一定程度上解决了这个问题。乐观锁,大多是基于数据版本(Version)记录机制实现。何谓数据版本?即为数据增加一个版本标识,在基于数据库表的版本解决方案中,一般是通过为数据库表增加一个 “version” 字段来实现。

    读取出数据时,将此版本号一同读出,之后更新时,对此版本号加一。此时,将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对,如果提交的数据版本号大于数据库表当前版本号,则予以更新,否则认为是过期数据。

    对于上面修改用户帐户信息的例子而言,假设数据库中帐户信息表中有一个version字段,当前值为1;而当前帐户余额字段(balance)为1000元。假设操作员A先更新完,操作员B后更新。
    a、操作员A此时将其读出(version=1),并从其帐户余额中增加100(1000+100=1100)。
    b、在操作员A操作的过程中,操作员B也读入此用户信息(version=1),并从其帐户余额中扣除50(1000-50=950)。
    c、操作员A完成了修改工作,将数据版本号加一(version=2),连同帐户增加后余额(balance=1100),提交至数据库更新,此时由于提交数据版本大于数据库记录当前版本,数据被更新,数据库记录version更新为2。
    d、操作员B完成了操作,也将版本号加一(version=2)试图向数据库提交数据(balance=950),但此时比对数据库记录版本时发现,操作员B提交的数据版本号为2,数据库记录当前版本也为2,不满足 “提交版本必须大于记录当前版本才能执行更新 “的乐观锁策略,因此,操作员B的提交被驳回。
    这样,就避免了操作员B用基于version=1的旧数据修改的结果覆盖操作员A的操作结果的可能。

    乐观锁介绍:

    乐观锁( Optimistic Locking ) 相对悲观锁而言,乐观锁假设认为数据一般情况下不会造成冲突,所以在数据进行提交更新的时候,才会正式对数据的冲突与否进行检测,如果发现冲突了,则让返回用户错误的信息,让用户决定如何去做。那么我们如何实现乐观锁呢,一般来说有以下2种方式:

    1、使用版本号实现乐观锁

    版本号的实现方式有两种,一个是数据版本机制,一个是时间戳机制。具体如下。

    a.使用数据版本(Version)记录机制实现,这是乐观锁最常用的一种实现方式。何谓数据版本?即为数据增加一个版本标识,一般是通过为数据库表增加一个数字类型的 “version” 字段来实现。当读取数据时,将version字段的值一同读出,数据每更新一次,对此version值加一。当我们提交更新的时候,判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对,如果数据库表当前版本号与第一次取出来的version值相等,则予以更新,否则认为是过期数据。用下面的一张图来说明:
    在这里插入图片描述
    如上图所示,如果更新操作顺序执行,则数据的版本(version)依次递增,不会产生冲突。但是如果发生有不同的业务操作对同一版本的数据进行修改,那么,先提交的操作(图中B)会把数据 version 更新为2,当A在B之后提交更新时发现数据的 version 已经被修改了,那么A的更新操作会失败。

    b.时间戳机制,同样是在需要乐观锁控制的 table 中增加一个字段,名称无所谓,字段类型使用时间戳(timestamp), 和上面的version类似,也是在更新提交的时候检查当前数据库中数据的时间戳和自己更新前取到的时间戳进行对比,如果一致则OK,否则就是版本冲突。

    2、使用条件限制实现乐观锁

    这个适用于只更新是做数据安全校验,适合库存模型,扣份额和回滚份额,性能更高。这种模式也是目前我用来锁产品库存的方法,十分方便实用。

    使用版本号实现乐观锁

    还是拿之前的实例来举:商品goods表中有一个字段status,status为1代表商品未被下单,status为2代表商品已经被下单,那么我们对某个商品下单时必须确保该商品status为1。假设商品的id为1。

    下单操作包括3步骤:

    1.查询出商品信息

    select (status,status,version) from t_goods where id=#{id}
    

    2.根据商品信息生成订单

    3.修改商品status为2

    update t_goods 
    
    set status=2,version=version+1
    
    where id=#{id} and version=#{version};
    

    那么为了使用乐观锁,我们首先修改t_goods表,增加一个version字段,数据默认version值为1。

    t_goods表初始数据如下:

    mysql> select * from t_goods;  
    +----+--------+------+---------+  
    | id | status | name | version |  
    +----+--------+------+---------+  
    |  1 |      1 | 道具 |       1 |  
    |  2 |      2 | 装备 |       2 |  
    +----+--------+------+---------+  
    2 rows in set  
      
    mysql>  
    

    对于乐观锁的实现,我使用MyBatis来进行实践,具体如下:

    Goods实体类

    /** 
     * ClassName: Goods <br/> 
     * Function: 商品实体. <br/> 
     * date: 2013-5-8 上午09:16:19 <br/> 
     * @author chenzhou1025@126.com 
     */  
    public class Goods {  
    
        /** 
         * 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  
    }
    

    GoodsDao

    /** 
     * updateGoodsUseCAS:使用CAS(Compare and set)更新商品信息. <br/> 
     * 
     * @author chenzhou1025@126.com 
     * @param goods 商品对象 
     * @return 影响的行数 
     */  
    int updateGoodsUseCAS(Goods goods);
    

    mapper.xml

    <update id="updateGoodsUseCAS" parameterType="Goods">  
        <![CDATA[ 
            update t_goods 
            set status=#{status},name=#{name},version=version+1 
            where id=#{id} and version=#{version} 
        ]]>  
    </update>
    

    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?"成功":"失败"));  
    }
    

    输出结果:
    good id:1,goods status:1,goods name:道具,goods version:1
    good id:1,goods status:1,goods name:道具,goods version:1
    修改商品信息1成功
    修改商品信息2失败

    说明:
    在GoodsDaoTest测试方法中,我们同时查出同一个版本的数据,赋给不同的goods对象,然后先修改good1对象然后执行更新操作,执行成功。然后我们修改goods2,执行更新操作时提示操作失败。此时t_goods表中数据如下:

    mysql> select * from t_goods;  
    +----+--------+------+---------+  
    | id | status | name | version |  
    +----+--------+------+---------+  
    |  1 |      2 | 道具 |       2 |  
    |  2 |      2 | 装备 |       2 |  
    +----+--------+------+---------+  
    rows in set  
      
    mysql>
    

    我们可以看到 id为1的数据version已经在第一次更新时修改为2了。所以我们更新good2时update where条件已经不匹配了,所以更新不会成功,具体sql如下:

    update t_goods   
    set status=2,version=version+1  
    where id=#{id} and version=#{version}; 
    

    这样我们就用版本号实现了乐观锁
    其实这种版本号的方法并不是适用于所有的乐观锁场景。举个例子,当电商抢购活动时,大量并发进入,如果仅仅使用版本号或者时间戳,就会出现大量的用户查询出库存存在,但是却在扣减库存时失败了,而这个时候库存是确实存在的。想象一下,版本号每次只会有一个用户扣减成功,不可避免的人为造成失败。这种时候就需要我们的第二种场景的乐观锁方法。

    使用条件限制实现乐观锁

    同样以上述案例为例。将表结构修改如下:

    mysql> select * from t_goods;  
    +----+--------+------+---------+  
    | id | status | name |    num  |  
    +----+--------+------+---------+  
    |  1 |      1 | 道具 |      10 |  
    |  2 |      2 | 装备 |      10 |  
    +----+--------+------+---------+  
    rows in set  
      
    mysql>
    

    status表示产品状态:1、在售。2、暂停出售。 num表示产品库存
    更新库存操作如下:

    UPDATE t_goods
    SET num = num - #{buyNum} 
    WHERE
        id = #{id} 
    AND num - #{buyNum} >= 0 
    AND STATUS = 1
    

    说明:num-#{buyNum}>=0 ,这个情景适合不用版本号,只更新是做数据安全校验,适合库存模型,扣份额和回滚份额,性能更高。这种模式也是目前我用来锁产品库存的方法,十分方便实用。
    注意:乐观锁的更新操作,最好用主键或者唯一索引来更新,这样是行锁,否则更新时会锁表

    展开全文
  • MYSQL乐观锁

    2020-02-21 10:24:37
    MYSQL乐观锁实现 对于按钮等控件,点击后使其立刻失效,不让用户重复点击,避免对同时对同一条记录操作。 使用乐观锁进行控制。乐观锁大多是基于数据版本(Version)记录机制实现。即为数据增加一个版本标识,在...

    MYSQL乐观锁实现

    1. 对于按钮等控件,点击后使其立刻失效,不让用户重复点击,避免对同时对同一条记录操作。
    2. 使用乐观锁进行控制。乐观锁大多是基于数据版本(Version)记录机制实现。即为数据增加一个版本标识,在基于数据库表的版本解决 方案中,一般是通过为数据库表增加一个“version”字段来实现。读取出数据时,将此版本号一同读出,之后更新时,对此版本号加一。此时,将提交数据 的版本数据与数据库表对应记录的当前版本信息进行比对,如果提交的数据版本号大于数据库表当前版本号,则予以更新,否则认为是过期数据。
    3. 乐观锁机制避免了 长事务中的数据库加锁开销(用户A和用户B操作过程中,都没有对数据库数据加锁),大大提升了大并发量下的系统整体性能表现。hibernate 在其数据访问引擎中内置了乐观锁实现。
    4. 需要注意的是,由于乐观锁机制是在我们的系统中实现,来自外部系统的用户更新操作不受我们系统的控制,因此可能会造成脏数据被更新到数据库中。
    5. 核心sql代码:
      UPDATE TABLE
      SET x = x + 1,
      version = version + 1
      WHERE
      id = {id} and version={version};

    个人总结:

    1. java的乐观锁和mysql乐观锁实现很接近;
    2. 都是用一个当前值V(version_now),预期值A(version_perdict),修改值B(version_update);
    3. 预期值A等于当前值V,就将当前值修改为B;
    展开全文
  • MySQL乐观锁

    2017-12-30 16:16:54
    MySQL乐观锁概述 乐观锁( Optimistic Locking ) 相对悲观锁而言,乐观锁假设认为数据一般情况下不会造成冲突,所以在数据进行提交更新的时候,才会正式对数据的冲突与否进行检测,如果发现冲突了,则返回给用户...

    MySQL乐观锁

    概述

    • 乐观锁( Optimistic Locking )
    • 相对悲观锁而言,乐观锁假设认为数据一般情况下不会造成冲突,所以在数据进行提交更新的时候,才会正式对数据的冲突与否进行检测,如果发现冲突了,则返回给用户错误的信息,让用户决定如何去做

    实现方式

    添加额外字段Version

    • 使用数据版本(Version)记录机制实现
    • 数据版本:即为数据增加一个版本标识,一般是通过为数据库表增加一个数字类型的 “version” 字段来实现。当读取数据时,将version字段的值一同读出,数据每更新一次,对此version值加一。
    • 当提交更新的时候,判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对,如果数据库表当前版本号与第一次取出来的version值相等,则予以更新,否则认为是过期数据
    • compare and swap 先比较一致再更新

    乐观锁-通过添加version实现

    // 左侧:按顺序提交,不会发生冲突
    // 右侧:version = 1 后,分别有 A B 两个事务读取到了 version = 1 的数据,都对此数据进行修改,B 先于 A 修改完毕并提交,修改完毕后 version = 2 ; A 提交修改操作,A 此时持有的 version = 1 ,但当前的 verison = 2 ,所以 A 事务的操作失败

    添加额外字段时间戳

    • table中增加一个字段类型使用时间戳(timestamp), 和上面的version类似,也是在更新提交的时候检查当前数据库中数据的时间戳和自己更新前取到的时间戳进行对比,如果一致则OK,否则就是版本冲突

    参考资料

    展开全文
  • Mysql 乐观锁

    2020-05-22 14:28:36
    乐观锁概述: 乐观锁又名版本锁, 乐观锁从某程度上可以解决并发. 具体操作看代码: SELECT id, version FROM table_name where id = #{id} 在执行操作之前需要查询要操作数据的版本信息. UPDATE table_name SET NAME...

    乐观锁概述: 乐观锁又名版本锁, 乐观锁从某程度上可以解决并发. 具体操作看代码:

    SELECT id, version  FROM table_name  where id = #{id}
    在执行操作之前需要查询要操作数据的版本信息. 
    
    UPDATE table_name  SET NAME = '', version = version + 1  WHERE id = #{id} and  version = #{version}
    操作完成后把对应的版本号加1 从而防止竞争同一资源的线程执行相同操作.  
    
    展开全文
  • mysql乐观锁

    2018-05-21 20:35:56
    一篇文章《MySQL悲观锁总结和实践》谈到了MySQL悲观锁,但是悲观锁并不是适用于任何场景,它也有它存在的一些不足,因为悲观锁大多数情况下依靠...所以与悲观锁相对的,我们有了乐观锁,具体参见下面介绍: 乐观...
  • MySQL 乐观锁

    2017-04-01 09:51:41
    上一篇文章《MySQL悲观锁总结和实践》谈到了MySQL悲观锁,但是悲观锁并不是适用于任何场景,它也有它存在的一些不足,因为悲观锁大多数情况下依靠数据库的锁...所以与悲观锁相对的,我们有了乐观锁,具体参见下面介绍:
  • mysql 乐观锁

    2019-03-09 22:14:45
    乐观锁 用数据版本(Version)记录机制实现,这是乐观锁最常用的一种实现方式。何谓数据版本?即为数据增加一个版本标识,一般是通过为数据库表增加一个数字类型的 “version” 字段来实现。当读取数据时,将...
  • mysql乐观锁实例

    2020-06-30 20:38:44
    mysql乐观锁介绍例子 介绍 mysql乐观锁是mvcc的一种实现。 mvcc就是multiple version concurrent control。 所谓乐观锁,就是假设数据不会冲突。所以你可以尽情地update,submit。如果发现有并发问题了,mysql可以将...
  • MySQL 乐观锁与悲观锁

    千次阅读 2017-02-24 15:36:51
    MySQL 乐观锁与悲观锁
  • MySQL 乐观锁和悲观锁

    2020-09-01 09:42:02
    MySQL 乐观锁和悲观锁悲观锁乐观锁 数据库管理系统(DBMS)中的并发控制的任务是确保在多个事务同时存取数据库中同一数据时不破坏事务的隔离性和统一性以及数据库的统一性。 乐观并发控制(乐观锁)和悲观并发控制...
  • 在创作该文当天下午,看见某篇秒杀技术博客的文章说道利用mysql乐观锁提高并发(原文如下) 悲观锁虽然可以解决超卖问题,但是加锁的时间可能会很长, 会长时间的限制其他用户的访问,导致很多请求等待锁, 卡死在这里...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 2,571
精华内容 1,028
关键字:

mysql乐观锁

mysql 订阅