【PHP】针对业务场景的需要,合理的使用 MySQL 乐观锁与悲观锁

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

何为悲观锁

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

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

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

何为乐观锁

乐观锁(Optimistic Lock):就是很乐观,每次去获取数据时,都认为其他人不会修改它,因此不会锁定,但是在提交更新时会判断在此期间其他人是否有去更新此数据。乐观锁适用于读多写少的应用场景,这样可以提高吞吐量。

也就是说,乐观锁就是假设不会发生并发冲突,只在提交操作时检查是否违反数据完整性。

悲观锁与乐观锁的区别

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)用悲观锁的方案:悲观锁,也就是在修改数据的时候,采用锁定状态,排斥外部请求的修改。遇到加锁的状态,就必须等待。

在这里插入图片描述

方案:使用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,先进先出),这样的话,我们就不会导致某些请求永远获取不到锁。

在这里插入图片描述

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

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

在这里插入图片描述

我们用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. 读取频繁时使用乐观锁,写入频繁时则使用悲观锁。还有一点:乐观锁不能解决脏读的问题。

点关注,不迷路

好了各位,以上就是这篇文章的全部内容了,能看到这里的人呀,都是人才。之前说过,PHP方面的技术点很多,也是因为太多了,实在是写不过来,写过来了大家也不会看的太多,所以我这里把它整理成了PDF和文档,如果有需要的可以

点击进入暗号: PHP+「平台」

在这里插入图片描述

在这里插入图片描述


更多学习内容可以访问【对标大厂】精品PHP架构师教程目录大全,只要你能看完保证薪资上升一个台阶(持续更新)

以上内容希望帮助到大家,很多PHPer在进阶的时候总会遇到一些问题和瓶颈,业务代码写多了没有方向感,不知道该从那里入手去提升,对此我整理了一些资料,包括但不限于:分布式架构、高可扩展、高性能、高并发、服务器性能调优、TP6,laravel,YII2,Redis,Swoole、Swoft、Kafka、Mysql优化、shell脚本、Docker、微服务、Nginx等多个知识点高级进阶干货需要的可以免费分享给大家,需要的可以加入我的 PHP技术交流群

原文地址:https://www.cnblogs.com/it-abu/p/14038394.html