php高并发状态下文件的读写

背景

1、对于PV不高或者说并发数不是很大的应用,不用考虑这些,一般的文件操作方法完全没有问题

2、如果并发高,在我们对文件进行读写操作时,很有可能多个进程对进一文件进行操作,如果这时不对文件的访问进行相应的独占,就容易造成数据丢失

例如:一个在线聊天室(这里假定把聊天内容写入文件),在同一时刻,用户A和用户B都要操作数据保存文件,首先是A打开了文件,然后更新里面的数据,但这 里B也正好也打开了同一个文件,也准备更新里面的数据。当A把写好的文件保存时,这里其实B已经打开了文件。但当B再把文件保存回去时,这里已经造成了数 据的丢失,因为这里B用户完全不知道它所打开的文件在它对其进行更改时,A用户也更改了这个文件,所以最后B用户保存更改时,用户A的更新就被会丢失。

对于这样的问题,一般的解决方案

1、当一进程对文件进行操作时,首先对其它进行加锁

2、这里只有该进程有权对文件进行读取,其它进程如果现在读,是完全没有问题,但如果这时有进程试图想对其进行更新,会遭到操作拒绝,

3、先前对文件进行加锁的进程这时如果对文件的更新操作完毕,这就释放独占的标识,这时文件又恢复到了可更改的状态

4、接下来同理,如果那个进程在操作文件时,文件没有加锁,这时,它就可以放心大胆的对文件进行锁定,独自享用

所以一般的方案会是

$fp = fopen("/tmp/lock.txt", "w+");
if (flock($fp, LOCK_EX)) {
    fwrite($fp, "Write something here\n");
    flock($fp, LOCK_UN);
} else {
    echo "Couldn‘t lock the file !";
}
fclose($fp);

但在PHP中,flock似乎工作的不是那么好!在多并发情况下,似乎是经常独占资源,不即时释放,或者是根本不释放,造成死锁,从而使服务器的cpu占用很高,甚至有时候会让服务器彻底死掉。好像在很多linux/unix系统中,都会有这样的情况发生。

所以使用flock之前,一定要慎重考虑。

那么就没有解决方案了吗?其实也不是这样的。如果flock()我们使用得当,完全可能解决死锁的问题。当然如果不考虑使用flock()函数,也同样会有很好的解决方案来解决我们的问题。

方案一:对文件进行加锁时,设置一个超时时间.

大致实现如下:

if($fp = fopen($fileName, ‘a‘)) {
	$startTime = microtime();
	do {
	        $canWrite = flock($fp, LOCK_EX);
		if(!$canWrite) usleep(round(rand(0, 100)*1000));
	} while ((!$canWrite) && ((microtime()-$startTime) < 1000));

	if ($canWrite) {
	  fwrite($fp, $dataToSave);
	}
	fclose($fp);
}

超时设置为1ms,如果这里时间内没有获得锁,就反复获得,直接获得到对文件操作权为止,当然。如果超时限制已到,就必需马上退出,让出锁让其它进程来进行操作。

方案二:不使用flock函数,借用临时文件来解决读写冲突的问题

大致原理如下:

1、将需要更新的文件copy一份到我们的临时文件目录,将文件最后修改时间保存到一个变量,并为这个临时文件取一个随机的,不容易重复的文件名

2、当对这个临时文件进行更新后,再检测原文件的最后更新时间和先前所保存的时间是否一致

3、如果最后一次修改时间一致,就将所修改的临时文件重命名到原文件,为了确保文件状态同步更新,所以需要清除一下文件状态

4、但是,如果最后一次修改时间和先前所保存的一致,这说明在这期间,原文件已经被修改过,这时,需要把临时文件删除,然后返回false,说明文件这时有其它进程在进行操作

大致实现代码如下:

$dir_fileopen = "tmp";

function randomid() {
    return time().substr(md5(microtime()), 0, rand(5, 12));
}
function cfopen($filename, $mode) {
    global $dir_fileopen;
    clearstatcache();
    do {
        $id = md5(randomid(rand(), TRUE));
        $tempfilename = $dir_fileopen."/".$id.md5($filename);
    } while(file_exists($tempfilename));
    if (file_exists($filename)) {
        $newfile = false;
        copy($filename, $tempfilename);
    }else{
        $newfile = true;
    }
    $fp = fopen($tempfilename, $mode);
    return $fp ? array($fp, $filename, $id, @filemtime($filename)) : false;
}
function cfwrite($fp,$string) { return fwrite($fp[0], $string); }
function cfclose($fp, $debug = "off") {
    global $dir_fileopen;
    $success = fclose($fp[0]);
    clearstatcache();
    $tempfilename = $dir_fileopen."/".$fp[2].md5($fp[1]);
    if ((@filemtime($fp[1]) == $fp[3]) || ($fp[4]==true && !file_exists($fp[1])) || $fp[5]==true) {
        rename($tempfilename, $fp[1]);
    }else{
        unlink($tempfilename);
		//说明有其它进程 在操作目标文件,当前进程被拒绝
        $success = false;
    }
    return $success;
}
$fp = cfopen(‘lock.txt‘,‘a+‘);
cfwrite($fp,"welcome to beijing.\n");
fclose($fp,‘on‘);

对于上面的代码所使用的函数,需要说明一下:

1.rename() 重命名一个文件或一个目录,该函数其实更像linux里的mv。更新文件或者目录的路径或名字很方便,但当在window测试上面代码时,如果新文件名已经存在,会给出一个notice,说当前文件已经存在,在linux下工作的很好

2.clearstatcache();清除文件的状态.php将缓存所有文件属性信息,以提供更高的性能,但有时,多进程在对文件进行删除或者更新操作
时,php没来得及更新缓存里的文件属性,容易导致访问到最后更新时间不是真实的数据。所以这里需要使用该函数对已保存的缓存进行清除。

方案三:对操作的文件进行随机读写,以降低并发的可能性

在对用户访问日志进行记录时,这种方案似乎被采用的比较多

先前需要定义一个随机空间,空间越大,并发的的可能性就越小,这里假设随机读写空间为[1-500],那么我们的日志文件的分布就为log1~到log500不等。每一次用户访问,都将数据随机写到log1~log500之间的任一文件

在同一时刻,有2个进程进行记录日志,A进程可能是更新的log32文件,而B进程呢?则此时更新的可能就为log399.要知道,如果要让B进程也操作log32,概率基本上为1/500,差不多约等于零

在需要对访问日志进行分析时,这里我们只需要先将这些日志合并,再进行分析即可

使用这种方案来记录日志的一个好处时,进程操作排队的可能性比较小,可以使进程很迅速的完成每一次操作

方案四:将所有要操作的进程放入一个队列中。然后专门放一个服务完成文件操作

队列中的每一个排除的进程相当于第一个具体的操作,所以第一次我们的服务只需要从队列中取得相当于具体操作事项就可以了,如果这里还有大量的文件操作进程,没关系,排到我们的队列后面即可,只要愿意排,队列的多长都没关系。

对于以前几种方案,各有各的好处!大致可能归纳为两类:

1、需要排队(影响慢)比如方案一、二、四

2、不需要排队。(影响快)方案三

在设计缓存系统时,一般我们不会采用方案三。因为方案三的分析程序和写入程序是不同步的,在写的时间,完全不考虑到时候分析的难度,只管写的行了。试想一
下,如我们在更新一个缓存时,如果也采用随机文件读写法,那么在读缓存时似乎会增加很多流程。但采取方案一、二就完全不一样,虽然写的时间需要等待(当获
取锁不成功时,会反复获取),

但读文件是很方便的。添加缓存的目的就是要减少数据读取瓶颈,从而提高系统性能。

原文地址:http://hqlong.com/2009/01/530.html

时间: 2024-08-06 07:59:27

php高并发状态下文件的读写的相关文章

高并发状态下修改数据库的操作

在高并发状态下,尤其数据在频繁修改的状态下,很可能出现脏数据,也有可能造成脏读,不可重复读等问题,那么怎么解决这种问题呢,其实解决方式有很多中,我们探讨出来的结果是,在频繁修改的表里面添加一个时间戳或者随机数的字段,例如,timestamp. 原理是当每一次修改数据的时候都要把之前的时间戳修改成当前的时间戳,并且之前的时间戳要作为where条件,如果之前的时间戳和参数里面的时间戳不一致,则修改失败,在重新查询进行反复操作,上代码: try {  if (count>5) {    return 

读/写锁的实现和应用(高并发状态下的map实现)

程序中涉及到对一些共享资源的读和写操作,且写操作没有读操作那么频繁.在没有写操作的时候,两个线程同时读一个资源没有任何问题,所以应该允许多个线程能在同时读取共享资源.但是如果有一个线程想去写这些共享资源,就不应该再有其它线程对该资源进行读或写(译者注:也就是说:读-读能共存,读-写不能共存,写-写不能共存).这就需要一个读/写锁来解决这个问题. 按照上面的叙述,简单的实现出一个读/写锁 public class ReadWriteLock{ private int readers = 0; pr

高并发压力下导致数据库bug

环境信息:  linux 6.1 + oracle11.2.0.3 RAC 问题现象: 学校晚上6点选课,人数大概有3000,7点时,数据库报错如下(数据库到6点多还是可以连接的),数据库hung住了. Tue Dec 16 18:00:33 2014Dumping diagnostic data in directory=[cdmp_20141216180033], requested by (instance=2, osid=24917 (M001)), summary=[incident=

大话程序猿眼里的高并发(下)

大话程序猿眼里的高并发(下) 前言 高并发经常会发生在有大活跃用户量,用户高聚集的业务场景中,如:秒杀活动,定时领取红包等. 为了让业务可以流畅的运行并且给用户一个好的交互体验,我们需要根据业务场景预估达到的并发量等因素,来设计适合自己业务场景的高并发处理方案. 在电商相关产品开发的这些年,我有幸的遇到了并发下的各种坑,这一路摸爬滚打过来有着不少的血泪史,这里进行的总结,作为自己的归档记录,同时分享给大家. 服务器架构 业务从发展的初期到逐渐成熟,服务器架构也是从相对单一到集群,再到分布式服务.

[转]高并发访问下避免对象缓存失效引发Dogpile效应

避免Redis/Memcached缓存失效引发Dogpile效应 Redis/Memcached高并发访问下的缓存失效时可能产生Dogpile效应(Cache Stampede效应). 推荐阅读:高并发下的 Nginx 优化方案 http://www.linuxidc.com/Linux/2013-01/78791.htm 避免Memcached缓存的Dogpile效应 Memcached的read-through cache流程:客户端读取缓存,没有的话就由客户端生成缓存.Memcached缓

数据库 之 高并发环境下的规则

原文:数据库 之 高并发环境下的规则 本文大部分转至沈剑老师,加上自己的一些见解. 本文前提 高并发环境 规则要点 1) 数据库字符集使用utf8mb4 无乱码风险.万国码 2)禁止使用存储过程.视图.触发器.Event 高并发大数据的互联网业务,架构设计思路是"解放数据库CPU,将计算转移到服务层",并发量大的情况下,这些功能很可能将数据库拖死,业务逻辑放到服务层具备更好的扩展性,能够轻易实现"增机器就加性能".数据库擅长存储与索引,CPU计算还是上移吧 3)禁止

高并发场景下的限流策略

高并发场景下的限流策略: 在开发高并发系统时,有很多手段来保护系统:缓存.降级.限流. 当访问量快速增长.服务可能会出现一些问题(响应超时),或者会存在非核心服务影响到核心流程的性能时, 仍然需要保证服务的可用性,即便是有损服务.所以意味着我们在设计服务的时候,需要一些手段或者关键数据进行自动降级,或者配置人工降级的开关. 缓存的目的是提升系统访问速度和增大系统处理的容量,可以说是抗高并发流量的银弹:降级是当服务出问题或者影响到核心流程的性能则需要暂时屏蔽掉某些功能,等高峰或者问题解决后再打开:

Tomcat 9.0.26 高并发场景下DeadLock问题排查与修复

本文首发于 vivo互联网技术 微信公众号? 链接:https://mp.weixin.qq.com/s/-OcCDI4L5GR8vVXSYhXJ7w 作者:黄卫兵.陈锦霞 一.Tomcat容器 9.0.26 版本 Deadlock 问题 1.1 问题现象 1.1.1? 发生 Deadlock 的背景 某接口/get.do压测,3分钟后,成功事务数TPS由1W骤降至0. 1.1.2? Tomcat服务器出现大量的CLOSE_WAIT 被压测服务器,出现TCP CLOSE_WAIT状态个数在200

高并发场景下缓存+数据库双写不一致问题分析与解决方案设计

Redis是企业级系统高并发.高可用架构中非常重要的一个环节.Redis主要解决了关系型数据库并发量低的问题,有助于缓解关系型数据库在高并发场景下的压力,提高系统的吞吐量(具体Redis是如何提高系统的性能.吞吐量,后面会专门讲). 而我们在Redis的实际使用过程中,难免会遇到缓存与数据库双写时数据不一致的问题,这也是我们必须要考虑的问题.如果还有同学不了解这个问题,可以搬小板凳来听听啦. 一.数据库+缓存双写不一致问题引入 要讲数据库+缓存双写不一致的问题,就需要先讲一下这个问题是怎么发生的