PHP 并发场景的几种解决方案

在秒杀,抢购等并发场景下,可能会出现超卖的现象,在PHP语言中并没有原生提供并发的解决方案,因此就需要借助其他方式来实现并发控制。

列出常见的解决方案有:

  • 使用队列,额外起一个进程处理队列,并发请求都放到队列中,由额外进程串行处理,并发问题就不存在了,但是要额外进程支持以及处理延迟严重,本文不先不讨论这种方法。
  • 利用数据库事务特征,做原子更新,此方法需要依赖数据库的事务特性。
  • 借助文件排他锁,在处理下单请求的时候,用flock锁定一个文件,成功拿到锁的才能处理订单。

一、利用 Redis 事务特征

redis 事务是原子操作,可以保证订单处理的过程中数据没有被其它并发的进程修改。

示例代码:

<?php
$http = new swoole_http_server("0.0.0.0", 9509);  // 监听 9509

$http->set(array(
  'reactor_num' => 2, //reactor thread num
  'worker_num' => 4  //worker process num
));

$http->on('request', function (swoole_http_request $request, swoole_http_response $response) {
  $uniqid = uniqid('uid-', TRUE);  // 模拟唯一用户ID
  $redis = new Redis();
  $redis->connect('127.0.0.1', 6379);  // 连接 redis

  $redis->watch('rest_count'); // 监测 rest_count 是否被其它的进程更改

  $rest_count = intval($redis->get("rest_count")); // 模拟唯一订单ID
  if($rest_count > 0){
    $value = "{$rest_count}-{$uniqid}"; // 表示当前订单,被当前用户抢到了

    // do something ... 主要是模拟用户抢到单后可能要进行的一些密集运算
    $rand = rand(100, 1000000);
    $sum=0;
    for ($i=0;$i<$rand;$i++){ $sum+=$i; }

   // redis 事务
    $redis->multi();
    $redis->lPush('uniqids', $value);
    $redis->decr('rest_count');
    $replies = $redis->exec(); // 执行以上 redis 事务

   // 如果 rest_count 的值被其它的并发进程更改了,以上事务将回滚
    if(!$replies){
      echo "订单 {$value} 回滚".PHP_EOL;
    }
  }
  $redis->unwatch();
});

$http->start();

使用 ab 测试

$ ab -t 20 -c 10 http://192.168.1.104:9509/

二、利用文件排他锁(阻塞模式)

阻塞模式下,如果进程在获取文件排他锁时,其它进程正在占用锁的话,此进程会挂起等待其它进程释放锁后,并自己获取到锁后,再往下执行。

示例代码:

<?php
$http = new swoole_http_server("0.0.0.0", 9510);

$http->set(array(
  'reactor_num' => 2, //reactor thread num
  'worker_num' => 4  //worker process num
));

$http->on('request', function (swoole_http_request $request, swoole_http_response $response) {

  $uniqid = uniqid('uid-', TRUE);
  $redis = new Redis();
  $redis->connect('127.0.0.1', 6379);

  $fp = fopen("lock.txt", "w+");

  // 阻塞(等待)模式, 要取得独占锁定(写入的程序)
  if(flock($fp,LOCK_EX))  //锁定当前指针
  {
   // 成功取得锁后,放心处理订单
    $rest_count = intval($redis->get("rest_count"));
    $value = "{$rest_count}-{$uniqid}";
    if($rest_count > 0){
      // do something ...
      $rand = rand(100, 1000000);
      $sum=0;
      for ($i=0;$i<$rand;$i++){ $sum+=$i; }

      $redis->lPush('uniqids', $value);
      $redis->decr('rest_count');
    }

   // 订单处理完成后,再释放锁
    flock($fp,LOCK_UN);
  }
  fclose($fp);

});

$http->start();

使用 ab 测试

$ ab -t 20 -c 10 http://192.168.1.104:9510/

三、利用文件排他锁(非阻塞模式)

非阻塞模式下,如果进程在获取文件排他锁时,其它进程正在占用锁的话,此进程会马上判断获取锁失败,并且继续往下执行。

示例代码:

<?php
$http = new swoole_http_server("0.0.0.0", 9511);

$http->set(array(
  'reactor_num' => 2, //reactor thread num
  'worker_num' => 4  //worker process num
));

$http->on('request', function (swoole_http_request $request, swoole_http_response $response) {

  $uniqid = uniqid('uid-', TRUE);
  $redis = new Redis();
  $redis->connect('127.0.0.1', 6379);

  $fp = fopen("lock.txt", "w+");

  // 非阻塞模式, 如果不希望 flock() 在锁定时堵塞,则给 lock 加上 LOCK_NB
  if(flock($fp,LOCK_EX | LOCK_NB))  //锁定当前指针
  {
   // 成功取得锁后,放心处理订单
    $rest_count = intval($redis->get("rest_count"));
    $value = "{$rest_count}-{$uniqid}";
    if($rest_count > 0){
      // do something ...
      $rand = rand(100, 1000000);
      $sum=0;
      for ($i=0;$i<$rand;$i++){ $sum+=$i; }

      $redis->lPush('uniqids', $value);
      $redis->decr('rest_count');
    }

   // 订单处理完成后,再释放锁
    flock($fp,LOCK_UN);
  } else {
   // 如果获取锁失败,马上进入这里执行
    echo "{$uniqid} - 系统繁忙,请稍后再试".PHP_EOL;
  }
  fclose($fp);

});

$http->start();

使用 ab 测试

$ ab -t 20 -c 10 http://192.168.1.104:9511/

最后给出三种处理方式的测试结果比较

redis 事务方式:

......
Concurrency Level:   10
Time taken for tests:  20.005 seconds
Complete requests:   17537
Failed requests:    0
Total transferred:   2578380 bytes
HTML transferred:    0 bytes
Requests per second:  876.62 [#/sec] (mean)
Time per request:    11.407 [ms] (mean)
Time per request:    1.141 [ms] (mean, across all concurrent requests)
Transfer rate:     125.86 [Kbytes/sec] received
......

文件排他锁(阻塞模式):

......
Concurrency Level:   10
Time taken for tests:  20.003 seconds
Complete requests:   8205
Failed requests:    0
Total transferred:   1206282 bytes
HTML transferred:    0 bytes
Requests per second:  410.19 [#/sec] (mean)
Time per request:    24.379 [ms] (mean)
Time per request:    2.438 [ms] (mean, across all concurrent requests)
Transfer rate:     58.89 [Kbytes/sec] received
......

文件排他锁(非阻塞模式):

......
Concurrency Level:   10
Time taken for tests:  20.002 seconds
Complete requests:   8616
Failed requests:    0
Total transferred:   1266846 bytes
HTML transferred:    0 bytes
Requests per second:  430.77 [#/sec] (mean)
Time per request:    23.214 [ms] (mean)
Time per request:    2.321 [ms] (mean, across all concurrent requests)
Transfer rate:     61.85 [Kbytes/sec] received
......

经测试结果对比,redis 事务方式优于文件排他锁方式,而文件排他锁方式中,非阻塞模式优于阻塞模式。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持我们。

(0)

相关推荐

  • php多线程并发实现方法

    本文实例讲述了php多线程并发实现方法.分享给大家供大家参考,具体如下: java里多线程就是一个new thread的事情,php依赖apache靠着linux底层有一个多线程的办法. 这里就来说说如果你无法操控apache的服务器,如何模拟php并发 <?php if(function_exists('date_default_timezone_set')) { date_default_timezone_set('PRC'); } function a() { $time = time()

  • php中并发读写文件冲突的解决方案

    对于日IP不高或者说并发数不是很大的应用,一般不用考虑这些!用一般的文件操作方法完全没有问题.但如果并发高,在我们对文件进行读写操作时,很有可能多个进程对进一文件进行操作,如果这时不对文件的访问进行相应的独占,就容易造成数据丢失.例如:一个在线聊天室(这里假定把聊天内容写入文件),在同一时刻,用户A和用户B都要操作数据保存文件,首先是A打开了文件,然后更新里面的数据,但这里B也正好也打开了同一个文件,也准备更新里面的数据.当A把写好的文件保存时,这里其实B已经打开了文件.但当B再把文件保存回去时

  • php并发对MYSQL造成压力的解决方法

    PHP页面有一个浏览量统计每秒有200并发,造成insert给mysql造成很大压力 lnmp环境,其他页面内容都做了缓存了,没有多大的负载,就是这个浏览量统计功能,给mysql带来不小的压力,请问诸位有什么解决办法吗? 怎么都说不要用MySQL来做,每秒200并发对MySQL来说不算啥难事啊.而且换成Redis.Memcached,持久化姑且不说,业务代码和运维部署量都不小. 我给你几个建议,尽量让你的运维部署和业务代码改动小一些. 你可以做主从分离,不要在一个库上高并发插入同时还做大量统计运

  • PHP接口并发测试的方法(推荐)

    如下所示: header('Content-type:text/html; Charset=utf-8'); $uri = "输入你的url"; $data = array( 'test'=>1 ); $ch = curl_init(); // print_r($ch); curl_setopt($ch, CURLOPT_URL, $uri); curl_setopt($ch, CURLOPT_POST, 1); curl_setopt($ch, CURLOPT_HEADER,

  • 一个PHP并发访问实例代码

    复制代码 代码如下: <?php $start=$_GET['s']; $end=$_GET['e']; $requests = array(); for ($index = $start; $index < $end; $index++) { $url="http://www.essort.com/amfphp/services/curl/loadTest.php?uid=$index"; $requests[]=$url; } $main = curl_multi_in

  • PHP并发场景的三种解决方案代码实例

    在秒杀,抢购等并发场景下,可能会出现超卖的现象,在 PHP 语言中并没有原生提供并发的解决方案,因此就需要借助其他方式来实现并发控制,其实方案有很多种,今天只是举个栗子抛砖引玉,有其他更好的方案你可以自己去玩一玩就好了. 列出常见的3个解决方案有: 使用队列,额外起一个进程处理队列,并发请求都放到队列中,由额外进程串行处理,并发问题就不存在了,但是要额外进程支持以及处理延迟严重,本文不先不讨论这种方法. 利用数据库事务特征,做原子更新,此方法需要依赖数据库的事务特性. 借助文件排他锁,在处理下单

  • PHP 并发场景的几种解决方案

    在秒杀,抢购等并发场景下,可能会出现超卖的现象,在PHP语言中并没有原生提供并发的解决方案,因此就需要借助其他方式来实现并发控制. 列出常见的解决方案有: 使用队列,额外起一个进程处理队列,并发请求都放到队列中,由额外进程串行处理,并发问题就不存在了,但是要额外进程支持以及处理延迟严重,本文不先不讨论这种方法. 利用数据库事务特征,做原子更新,此方法需要依赖数据库的事务特性. 借助文件排他锁,在处理下单请求的时候,用flock锁定一个文件,成功拿到锁的才能处理订单. 一.利用 Redis 事务特

  • Redis高并发场景下秒杀超卖解决方案(秒杀场景)

    目录 1 什么是秒杀 2 为什么要防止超卖 3 单体架构常规秒杀 3.1 常规减库存代码 3.2 模拟高并发 3.3 超卖现象 3.4 分析原因 4 简单实现悲观乐观锁解决单体架构超卖 4.1 悲观锁 4.2 乐观锁 4.3 redis锁setnx 4.4 使用Redision 5 分布式锁的解决方案 6 采用缓存队列防止超卖 1 什么是秒杀 秒杀最直观的定义:在高并发场景下而下单某一个商品,这个过程就叫秒杀 [秒杀场景] 火车票抢票 双十一限购商品 热度高的明星演唱会门票 … 2 为什么要防止

  • PHP开发中解决并发问题的几种实现方法分析

    本文实例讲述了PHP开发中解决并发问题的几种实现方法.分享给大家供大家参考,具体如下: 对于商品抢购等并发场景下,可能会出现超卖的现象,这时就需要解决并发所带来的这些问题了 在PHP语言中并没有原生的提供并发的解决方案,因此就需要借助其他方式来实现并发控制. 方案一:使用文件锁排它锁 flock函数用于获取文件的锁,这个锁同时只能被一个线程获取到,其它没有获取到锁的线程要么阻塞,要么获取失败 在获取到锁的时候,先查询库存,如果库存大于0,则进行下订单操作,减库存,然后释放锁 方案二:使用Mysq

  • 详解MySQL双活同步复制四种解决方案

    对于数据实时同步,其核心是需要基于日志来实现,是可以实现准实时的数据同步,基于日志实现不会要求数据库本身在设计和实现中带来任何额外的约束. 基于MySQL原生复制主主同步方案  这是常见的方案,一般来说,中小型规模的时候,采用这种架构是最省事的. 两个节点可以采用简单的双主模式,并且使用专线连接,在master_A节点发生故障后,应用连接快速切换到master_B节点,反之也亦然.有几个需要注意的地方,脑裂的情况,两个节点写入相同数据而引发冲突,同时把两个节点的auto_increment_in

  • java的SimpleDateFormat线程不安全的几种解决方案

    目录 场景 SimpleDateFormat线程为什么是线程不安全的呢? 验证SimpleDateFormat线程不安全 解决方案 解决方案1:不要定义为static变量,使用局部变量 解决方案2:加锁:synchronized锁和Lock锁 加synchronized锁 加Lock锁 解决方案3:使用ThreadLocal方式 解决方案4:使用DateTimeFormatter代替SimpleDateFormat 解决方案5:使用FastDateFormat 替换SimpleDateForma

  • 关于MySQL与Golan分布式事务经典的七种解决方案

    目录 1.基础理论 1.1 事务 1.2 分布式事务 2.分布式事务的解决方案 2.1 两阶段提交/XA 2.2 SAGA 2.3 TCC 2.4 本地消息表 2.5 事务消息 2.6 最大努力通知 2.7 AT事务模式 3.异常处理 3.1 异常情况 3.2 子事务屏障 3.3 子事务屏障原理 3.4 子事务屏障小结 4.分布式事务实践 4.1 一个SAGA事务 4.2 处理网络异常 4.3 处理回滚 5.总结 前言: 随着业务的快速发展.业务复杂度越来越高,几乎每个公司的系统都会从单体走向分

  • 浅谈C++高并发场景下读多写少的优化方案

    目录 概述 分析 双缓冲 工程实现上需要攻克的难点 核心代码实现 简单说说golang中双缓冲的实现 相关文献 概述 一谈到高并发的优化方案,往往能想到模块水平拆分.数据库读写分离.分库分表,加缓存.加mq等,这些都是从系统架构上解决.单模块作为系统的组成单元,其性能好坏也能很大的影响整体性能,本文从单模块下读多写少的场景出发,探讨其解决方案,以其更好的实现高并发.不同的业务场景,读和写的频率各有侧重,有两种常见的业务场景: 读多写少:典型场景如广告检索端.白名单更新维护.loadbalance

  • 分享MySQL 主从延迟与读写分离的七种解决方案

    目录 一.强制走主库 二.从库延迟查询 三.判断主从是否延迟?决定选主库还是从库 1.针对这个问题,有什么解决方案? 四.从库节点判断主库位点 五.比较 GTID 六.引入缓存中间件 七.数据分片 1.转换到数据库方面 前言: 我们都知道互联网数据有个特性,大部分场景都是 读多写少,比如:微博.微信.淘宝电商,按照 二八原则,读流量占比甚至能达到 90%. 结合这个特性,我们对底层的数据库架构也会做相应调整.采用 读写分离. 处理过程: 客户端会集成 SDK,每次执行 SQL 时,会判断是 写

  • Java处理延时任务的常用几种解决方案

    目录 前言 数据库轮询 原理 优缺点 Java延迟队列 Reids监听失效key 创建监听类,实现MessageListener接口 RocketMq延迟消息 总结 前言 项目中经常会遇到如下的需求: 创建订单30分钟未支付,订单自动取消. 订单支付成功后,1分钟后给用户发送短信,提醒用户评价. … 针对延时任务需求,我们可以采用如下的解决方案: 数据库轮询 原理 通过一个线程定时的扫描数据库当天创建的订单,根据订单的创建时间来判断订单是否超时,针对超时订单进行相关的更新操作.实现技术采用Spr

随机推荐