mysql高级——并发安全控制悲观锁和乐观锁的实现

一、悲观锁
    1、排它锁，当事务在操作数据时把这部分数据进行锁定，直到操作完毕后再解锁，其他事务操作才可操作该部分数据。这将防止其他进程读取或修改表中的数据。

    2、实现：大多数情况下依靠数据库的锁机制实现

     一般使用 select ...forupdate 对所选择的数据进行加锁处理，例如select * from account where name=”Max”  for update， 这条sql 语句锁定了account 表中所有符合检索条件（name=”Max”）的记录。本次事务提交之前（事务提交时会释放事务过程中的锁），外界无法修改这些记录。

二、乐观锁
    1、如果有人在你之前更新了，你的更新应当是被拒绝的，可以让用户重新操作。

    2、实现：大多数基于数据版本（Version）记录机制实现

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

如上图所示，如果更新操作顺序执行，则数据的版本（version）依次递增，不会产生冲突。但是如果发生有不同的业务操作对同一版本的数据进行修改，那么，先提交的操作（图中B）会把数据version更新为2，当A在B之后提交更新时发现数据的version已经被修改了，那么A的更新操作会失败。

乐观锁定的第二种实现方式和第一种差不多，同样是在需要乐观锁控制的table中增加一个字段，名称无所谓，字段类型使用时间戳（timestamp）, 和上面的version类似，也是在更新提交的时候检查当前数据库中数据的时间戳和自己更新前取到的时间戳进行对比，如果一致则OK，否则就是版本冲突。

使用举例：以MySQL InnoDB为例 
还是拿之前的实例来举：商品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};

如在mybatis的mapper.xml

<update id="updateGoodsUseCAS" parameterType="Goods">

        update t_goods
        set status=#{status},name=#{name},version=version+1
        where id=#{id} and version=#{version}
    ]]>
update>

三、悲观锁和乐观锁的比较总结

     悲观锁相对比较谨慎，设想现实情况应该很容易就发生冲突，所以我还是独占数据资源吧。

     乐观锁就想得开而且非常聪明，应该是不会有什么冲突的，我对表使用一个时间戳或者版本号，每次读、更新操作都对这个字段进行比对，如果在我之前已经有人对数据进行更新了，那就让它更新，大不了我再读一次或者再更新一次。

     在实际生产环境里边,如果并发量不大且不允许脏读，可以使用悲观锁；但如果系统的并发非常大的话,悲观锁定会带来非常大的性能问题,所以我们就要选择乐观锁定的方法 。

参考:

http://blog.csdn.net/machihaoyu/article/details/71404347

http://blog.csdn.net/daybreak1209/article/details/51606939

↓↓↓本文来自公众号↓↓↓

聚焦程序猿的世界，探讨技艺，分享资源，侃谈生活……