秒杀抢购思路以及高并发下数据安全

  咱们一般衡量一个Web系统的吞吐率的指标是QPS（Query Per Second，每秒处理请求数），解决每秒数万次的高并发场景，这个指标很是关键。举个例子，咱们假设处理一个业务请求平均响应时间为100ms，同时，系统内有20台Web服务器，配置MaxClients为500个（表示服务器的最大链接数目）。

那么，咱们的Web系统的理论峰值QPS为（理想化的计算方式）：

20*500/0.1 = 100000 （10万QPS）

在高并发的实际场景下，机器都处于高负载的状态，在这个时候平均响应时间会被大大增长。

就Web服务器而言，他打开了越多的链接进程，CPU须要处理的上下文切换也越多，额外增长了CPU的消耗，而后就直接致使平均响应时间增长。所以上述的MaxClient数目，要根据CPU、内存等硬件因素综合考虑，绝对不是越多越好。能够经过Apache自带的ab来测试一下，取一个合适的值。而后，咱们选择内存操做级别的存储的Redis，在高并发的状态下，存储的响应时间相当重要。网络带宽虽然也是一个因素，不过，这种请求数据包通常比较小，通常不多成为请求的瓶颈。负载均衡成为系统瓶颈的状况比较少，在这里不作讨论哈。

那么问题来了，假设咱们的系统，在5w/s的高并发状态下，平均响应时间从100ms变为250ms（实际状况，甚至更多）：

20*500/0.25 = 40000 （4万QPS）

因而，咱们的系统剩下了4w的QPS，面对5w每秒的请求，中间相差了1w。

举个例子，高速路口，1秒钟来5部车，每秒经过5部车，高速路口运做正常。忽然，这个路口1秒钟只能经过4部车，车流量仍然依旧，结果一定出现大塞车。（5条车道突然变成4条车道的感受）

同理，某一个秒内，20*500个可用链接进程都在满负荷工做中，却仍然有1万个新来请求，没有链接进程可用，系统陷入到异常状态也是预期以内。

 

其实在正常的非高并发的业务场景中，也有相似的状况出现，某个业务请求接口出现问题，响应时间极慢，将整个Web请求响应时间拉得很长，逐渐将Web服务器的可用链接数占满，其余正常的业务请求，无链接进程可用。

更可怕的问题是，是用户的行为特色，系统越是不可用，用户的点击越频繁，恶性循环最终致使“雪崩”（其中一台Web机器挂了，致使流量分散到其余正常工做的机器上，再致使正常的机器也挂，而后恶性循环），将整个Web系统拖垮。

3. 重启与过载保护

若是系统发生“雪崩”，贸然重启服务，是没法解决问题的。最多见的现象是，启动起来后，马上挂掉。这个时候，最好在入口层将流量拒绝，而后再将重启。若是是redis/memcache这种服务也挂了，重启的时候须要注意“预热”，而且极可能须要比较长的时间。

秒杀和抢购的场景，流量每每是超乎咱们系统的准备和想象的。这个时候，过载保护是必要的。若是检测到系统满负载状态，拒绝请求也是一种保护措施。在前端设置过滤是最简单的方式，可是，这种作法是被用户“千夫所指”的行为。更合适一点的是，将过载保护设置在CGI入口层，快速将客户的直接请求返回

高并发下的数据安全

咱们知道在多线程写入同一个文件的时候，会存现“线程安全”的问题（多个线程同时运行同一段代码，若是每次运行结果和单线程运行的结果是同样的，结果和预期相同，就是线程安全的）。若是是MySQL数据库，可使用它自带的锁机制很好的解决问题，可是，在大规模并发的场景中，是不推荐使用MySQL的。秒杀和抢购的场景中，还有另一个问题，就是“超发”，若是在这方面控制不慎，会产生发送过多的状况。咱们也曾经据说过，某些电商搞抢购活动，买家成功拍下后，商家却不认可订单有效，拒绝发货。这里的问题，也许并不必定是商家奸诈，而是系统技术层面存在超发风险致使的。

1. 超发的缘由

假设某个抢购场景中，咱们一共只有100个商品，在最后一刻，咱们已经消耗了99个商品，仅剩最后一个。这个时候，系统发来多个并发请求，这批请求读取到的商品余量都是99个，而后都经过了这一个余量判断，最终致使超发。

 

在上面的这个图中，就致使了并发用户B也“抢购成功”，多让一我的得到了商品。这种场景，在高并发的状况下很是容易出现。

优化方案1：将库存字段number字段设为unsigned，当库存为0时，由于字段不能为负数，将会返回false

<?php
//优化方案1：将库存字段number字段设为unsigned，当库存为0时，由于字段不能为负数，将会返回false
include('./mysql.php');
$username = 'wang'.rand(0,1000);
//生成惟一订单
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,$username){
    global $conn;
    $sql="insert into ih_log(event,type,usernma)
    values('$event','$type','$username')";
    return mysqli_query($conn,$sql);
}
function insertOrder($order_sn,$user_id,$goods_id,$sku_id,$price,$username,$number)
{
      global $conn;
      $sql="insert into ih_order(order_sn,user_id,goods_id,sku_id,price,username,number)
      values('$order_sn','$user_id','$goods_id','$sku_id','$price','$username','$number')";
     return  mysqli_query($conn,$sql);
}
//模拟下单操做
//库存是否大于0
$sql="select number from ih_store where goods_id='$goods_id' and sku_id='$sku_id' ";
$rs=mysqli_query($conn,$sql);
$row = $rs->fetch_assoc();
  if($row['number']>0){//高并发下会致使超卖
      if($row['number']<$number){
        return insertLog('库存不够',3,$username);
      }
      $order_sn=build_order_no();
      //库存减小
      $sql="update ih_store set number=number-{$number} where sku_id='$sku_id' and number>0";
      $store_rs=mysqli_query($conn,$sql);
      if($store_rs){
          //生成订单
          insertOrder($order_sn,$user_id,$goods_id,$sku_id,$price,$username,$number);
          insertLog('库存减小成功',1,$username);
      }else{
          insertLog('库存减小失败',2,$username);
      }
  }else{
      insertLog('库存不够',3,$username);
  }


?>
2. 悲观锁思路

解决线程安全的思路不少，能够从“悲观锁”的方向开始讨论。

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

 

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

优化方案2：使用MySQL的事务，锁住操做的行

<?php
//优化方案2：使用MySQL的事务，锁住操做的行
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");
}
?>
3. FIFO队列思路

那好，那么咱们稍微修改一下上面的场景，咱们直接将请求放入队列中的，采用FIFO（First Input First Output，先进先出），这样的话，咱们就不会致使某些请求永远获取不到锁。看到这里，是否是有点强行将多线程变成单线程的感受哈。

 而后，咱们如今解决了锁的问题，所有请求采用“先进先出”的队列方式来处理。那么新的问题来了，高并发的场景下，由于请求不少，极可能一瞬间将队列内存“撑爆”，而后系统又陷入到了异常状态。或者设计一个极大的内存队列，也是一种方案，可是，系统处理完一个队列内请求的速度根本没法和疯狂涌入队列中的数目相比。也就是说，队列内的请求会越积累越多，最终Web系统平均响应时候仍是会大幅降低，系统仍是陷入异常。

附:RabbitMQ队列使用 -> https://my.oschina.net/wangjie404/blog/819141

4. 文件锁的思路

对于日IP不高或者说并发数不是很大的应用，通常不用考虑这些！用通常的文件操做方法彻底没有问题。但若是并发高，在咱们对文件进行读写操做时，颇有可能多个进程对进一文件进行操做，若是这时不对文件的访问进行相应的独占，就容易形成数据丢失

优化方案4：使用非阻塞的文件排他锁

<?php
//优化方案4：使用非阻塞的文件排他锁
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);
}


$fp = fopen("lock.txt", "w+");
if(!flock($fp,LOCK_EX | LOCK_NB)){
    echo "系统繁忙，请稍后再试";
    return;
}
//下单
$sql="select number from ih_store where goods_id='$goods_id' and sku_id='$sku_id'";
$rs =  mysqli_query($conn,$sql);
$row = $rs->fetch_assoc();
if($row['number']>0){//库存是否大于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('库存减小成功');
        flock($fp,LOCK_UN);//释放锁
    }else{
      echo '库存减小失败';
        insertLog('库存减小失败');
    }
}else{
  echo '库存不够';
    insertLog('库存不够');
}
fclose($fp);


 ?>
 

5. 乐观锁思路

这个时候，咱们就能够讨论一下“乐观锁”的思路了。乐观锁，是相对于“悲观锁”采用更为宽松的加锁机制，大都是采用带版本号（Version）更新。实现就是，这个数据全部请求都有资格去修改，但会得到一个该数据的版本号，只有版本号符合的才能更新成功，其余的返回抢购失败。这样的话，咱们就不须要考虑队列的问题，不过，它会增大CPU的计算开销。可是，综合来讲，这是一个比较好的解决方案。

 

有不少软件和服务都“乐观锁”功能的支持，例如Redis中的watch就是其中之一。经过这个实现，咱们保证了数据的安全。

优化方案5：Redis中的watch

<?php

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

$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;
    }
}
?>
附：RabbitMQ队列使用 -> https://my.oschina.net/wangjie404/blog/819141

　　转载：https://my.oschina.net/wangjie404/blog/815455