page contents

合理的使用MySQL乐观锁与悲观锁

针对 MySQL的乐观锁与悲观锁的使用,基本都是按照业务场景针对性使用的。针对每个业务场景,对应的使用锁。但是两种锁无非都是解决并发所产生的问题。下面我们来看看如何合理的使用乐观锁与悲观锁。

attachments-2020-08-PdQIef6M5f364c800eb0c.png

针对 MySQL的乐观锁与悲观锁的使用,基本都是按照业务场景针对性使用的。针对每个业务场景,对应的使用锁。

但是两种锁无非都是解决并发所产生的问题。下面我们来看看如何合理的使用乐观锁与悲观锁


何为悲观锁

悲观锁(Pessimistic Lock):就是很悲观,每次去取数据的时候都认为别人会去修改,所以每次在取数据的时候都会给它上锁,这样别人想拿这个数据就会block直到它取到锁。比如用在库存增减问题上,利用悲观锁可以有效的防止减库存问题。


简单来讲,悲观锁就是假定会发生并发冲突,屏蔽一切可能违反数据完整性的操作。悲观并发控制实际上是 “先取锁,再访问” 的保守策略,为数据处理的安全提供了保证。


在效率上,处理加锁的机制会让数据库产生额外的开销,还会有死锁的可能性。降低并行性,一个事务如果锁定了某行数据,其他事务就必须等待该事务处理完才可以处理那行数据。


悲观锁与乐观锁的区别

1 优缺点
两种锁各有优缺点,不可认为一种好于另一种,比如像乐观锁,适用于写比较少的情况下,冲突真的很少发生的时候,这样可以省去了锁的开销,加大了系统的整个吞吐量。但如果经常产生冲突,上层应用会不断的进行retry,这样反倒是降低了性能,所以这种情况下用悲观锁就比较合适。


2 实现方式
悲观锁的实现方式:悲观锁的实现,依靠数据库提供的锁机制。
在数据库中,悲观锁的流程如下:
1 在对数据修改前,尝试增加排他锁。
2 加锁失败,意味着数据正在被修改,进行等待或者抛出异常。
3 加锁成功,对数据进行修改,提交事务,锁释放。
4 如果我们加锁成功,有其他线程对该数据进行操作或者加排他锁的操作,只能等待或者抛出异常。


乐观锁的实现方式:
1)version方式:一般是在数据表中加上一个数据版本号version字段,表示数据被修改的次数,当数据被修改时,version值会加一。当线程A要更新数据值时,在读取数据的同时也会读取version值,在提交更新时,若刚才读取到的version值为当前数据库中的version值相等时才更新,否则重试更新操作,直到更新成功。


sql实现代码

update table set n=n+1, version=version+1 where id=#{id} and version=#{version};

2)CAS(定义见后)操作方式:即compare and swap 或者 compare and set,涉及到三个操作数,数据所在的内存值,预期值,新值。当需要更新时,判断当前内存值与之前取到的值是否相等,若相等,则用新值更新,若失败则重试,一般情况下是一个自旋操作,即不断的重试。


悲观锁与乐观锁的合理使用

本质上,MySQL的乐观锁与悲观锁主要都是用来解决并发的场景,避免丢失更新问题。
乐观锁:比较适合读取操作比较频繁的场景,如果出现大量的写入操作,数据发生冲突的可能性就会增大,为了保证数据的一致性,应用层需要不断的重新获取数据,这样会增加大量的查询操作,降低了系统的吞吐量。


悲观锁:比较适合写入操作比较频繁的场景,如果出现大量的读取操作,每次读取的时候都会进行加锁,这样会增加大量的锁的开销,降低了系统的吞吐量。


用一个场景与代码来详细的介绍一下如何合理使用,假设有这么一个商品秒杀和抢购的场景:在抢购场景中,一共只有100个商品,在最后一刻,已经消耗了99个商品,仅剩最后一个。这个时候,系统发来多个并发请求,这批请求读取到的商品余量都是99个,然后都通过了这一个余量判断,最终导致商品超发。也就是:导致了并发用户B也“抢购成功”,多让一个人获得了商品。


1 用悲观锁的方案:悲观锁,也就是在修改数据的时候,采用锁定状态,排斥外部请求的修改。遇到加锁的状态,就必须等待。

v2-8827794be1a222c97818087a90573b97_720w.jpg


方案:使用MySQL的事务,锁住操作的行

<?php

include('./mysql.php');

//生成唯一订单号
function build_order_no(){

  return date('ymd').substr(implode(NULL, array_map('ord', str_split(substr(uniqid(), 7, 13), 1))), 0, 8);
}

//记录日志
function insertLog($event,$type=0){

    global $conn;
    $sql="insert into ih_log(event,type)
    values('$event','$type')";
    mysqli_query($conn,$sql);

}



//模拟下单操作
//库存是否大于0
mysqli_query($conn,"BEGIN");  //开始事务

//此时这条记录被锁住,其它事务必须等待此次事务提交后才能执行
$sql="select number from ih_store where goods_id='$goods_id' and sku_id='$sku_id' FOR UPDATE";
$rs=mysqli_query($conn,$sql);
$row=$rs->fetch_assoc();

if($row['number']>0){
    //生成订单
    $order_sn=build_order_no();
    $sql="insert into ih_order(order_sn,user_id,goods_id,sku_id,price)
    values('$order_sn','$user_id','$goods_id','$sku_id','$price')";
    $order_rs=mysqli_query($conn,$sql);

    //库存减少
    $sql="update ih_store set number=number-{$number} where sku_id='$sku_id'";
    $store_rs=mysqli_query($conn,$sql);

    if($store_rs){

       echo '库存减少成功';
       insertLog('库存减少成功');
       mysqli_query($conn,"COMMIT");//事务提交即解锁

    }else{

      echo '库存减少失败';
      insertLog('库存减少失败');
    }

}else{

    echo '库存不够';
    insertLog('库存不够');
    mysqli_query($conn,"ROLLBACK");

}

上述的方案解决了线程安全的问题,但是,我们的场景是“高并发”。也就是说,会很多这样的修改请求,每个请求都需要等待“锁”,某些线程可能永远都没有机会抢到这个“锁”,这种请求就会死在那里。同时,这种请求会很多,瞬间增大系统的平均响应时间,结果是可用连接数被耗尽,系统陷入异常。


稍微修改一下上面的场景,我们直接将请求放入队列中的,采用FIFO(First Input First Output,先进先出),这样的话,我们就不会导致某些请求永远获取不到锁。

v2-044b9fbe3b1ff575d95f2828eaa4de0b_720w.jpg


全部请求采用“先进先出”的队列方式来处理,解决了锁的问题。但是新的问题来了,在高并发的场景下请求很多,可能一瞬间将队列内存“撑爆”,然后系统又陷入到了异常状态。这个时候,我们就可以用乐观锁来解决相关问题了。


上面也提到,乐观锁是相对于“悲观锁”采用更为宽松的加锁机制,大都是采用带版本号(Version)更新。实现就是这个数据所有请求都有资格去修改,但会获得一个该数据的版本号,只有版本号符合的才能更新成功,其他的返回抢购失败。这样的话,我们就不需要考虑队列的问题,不过它会增大CPU的计算开销。但是,综合来说,这是一个比较好的解决方案。

v2-f0d24d2edf26a1d350e971de9c008b7e_720w.jpg


我们用Redis中的watch来实现乐观锁,通过这个实现,保证数据的安全。

<?php

    $redis = new redis();
    $result = $redis->connect('127.0.0.1', 6379);
    echo $mywatchkey = $redis->get("mywatchkey");

    /*
    //插入抢购数据
    if($mywatchkey>0){
        $redis->watch("mywatchkey");

        //启动一个新的事务。
        $redis->multi();
        $redis->set("mywatchkey",$mywatchkey-1);
        $result = $redis->exec();

        if($result) {

          $redis->hSet("watchkeylist","user_".mt_rand(1,99999),time());
          $watchkeylist = $redis->hGetAll("watchkeylist");

            echo "抢购成功!<br/>";
            $re = $mywatchkey - 1;
            echo "剩余数量:".$re."<br/>";
            echo "用户列表:<pre>";
            print_r($watchkeylist);

        }else{
          echo "手气不好,再抢购!";exit;

        }

    }else{

         // $redis->hSet("watchkeylist","user_".mt_rand(1,99999),"12");
         // $watchkeylist = $redis->hGetAll("watchkeylist");

            echo "fail!<br/>";
            echo ".no result<br/>";
            echo "用户列表:<pre>";
          //var_dump($watchkeylist);

    }*/


    $rob_total = 100;   //抢购数量
    if($mywatchkey<=$rob_total){
        $redis->watch("mywatchkey");
        $redis->multi(); //在当前连接上启动一个新的事务。
        //插入抢购数据
        $redis->set("mywatchkey",$mywatchkey+1);
        $rob_result = $redis->exec();

        if($rob_result){

            $redis->hSet("watchkeylist","user_".mt_rand(1, 9999),$mywatchkey);
            $mywatchlist = $redis->hGetAll("watchkeylist");
            echo "抢购成功!<br/>";

            echo "剩余数量:".($rob_total-$mywatchkey-1)."<br/>";
            echo "用户列表:<pre>";
            var_dump($mywatchlist);

        }else{

            $redis->hSet("watchkeylist","user_".mt_rand(1, 9999),'meiqiangdao');
            echo "手气不好,再抢购!";exit;

        }

    }


总结
1 要记住锁机制一定要在事务中才能生效,事务也就要基于MySQL InnoDB 引擎。
2 访问量不大,不会造成压力时使用悲观锁,面对高并发的情况下,我们应该使用乐观锁。
3 读取频繁时使用乐观锁,写入频繁时则使用悲观锁。还有一点:乐观锁不能解决脏读的问题。


attachments-2020-08-8szlKpJI5f364c6d2c53b.jpg

  • 发表于 2020-08-14 16:34
  • 阅读 ( 686 )
  • 分类:数据库

你可能感兴趣的文章

相关问题

0 条评论

请先 登录 后评论
Pack
Pack

1135 篇文章

作家榜 »

  1. 轩辕小不懂 2403 文章
  2. 小柒 1474 文章
  3. Pack 1135 文章
  4. Nen 576 文章
  5. 王昭君 209 文章
  6. 文双 71 文章
  7. 小威 64 文章
  8. Cara 36 文章