對於日IP不高或者說並發數不是很大的應用，一般不用考慮這些!用一般的文件操作方法完全沒有問題。但如果並發高，在我們對文件進行讀寫操作時，很有可能多個進程對進一文件進行操作，如果這時不對文件的訪問進行相應的獨占，就容易造成數據丟失。
例如：一個在線聊天室(這裡假定把聊天內容寫入文件)，在同一時刻，用戶A和用戶B都要操作數據保存文件，首先是A打開了文件，然後更新裡面的數據，但這裡B也正好也打開了同一個文件，也准備更新裡面的數據。當A把寫好的文件保存時，這裡其實B已經打開了文件。但當B再把文件保存回去時，這裡已經造成了數據的丟失，因為這裡B用戶完全不知道它所打開的文件在它對其進行更改時，A用戶也更改了這個文件，所以最後B用戶保存更改時，用戶A的更新就被會丟失。
對於這樣的問題，一般的解決方案時當一進程對文件進行操作時，首先對其它進行加鎖，意味著這裡只有該進程有權對文件進行讀取，其它進程如果現在讀，是完全沒有問題，但如果這時有進程試圖想對其進行更新，會遭到操作拒絕，先前對文件進行加鎖的進程這時如果對文件的更新操作完畢，這就釋放獨占的標識，這時文件又恢復到了可更改的狀態。接下來同理，如果那個進程在操作文件時，文件沒有加鎖，這時，它就可以放心大膽的對文件進行鎖定，獨自享用。
所以一般的方案會是：
$fp=fopen('/tmp/lock.txt','w+');
if (flock($fp,LOCK_EX)){
fwrite($fp,"Write something heren");
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)將需要更新的文件考慮一份到我們的臨時文件目錄，將文件最後修改時間保存到一個變量，並為這個臨時文件取一個隨機的，不容易重復的文件名。
(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)不需要排隊。(影響快)方案三
在設計緩存系統時，一般我們不會采用方案三。因為方案三的分析程序和寫入程序是不同步的，在寫的時間，完全不考慮到時候分析的難度，只管寫的行了。試想一下，如我們在更新一個緩存時，如果也采用隨機文件讀寫法，那麼在讀緩存時似乎會增加很多流程。但采取方案一、二就完全不一樣，雖然寫的時間需要等待(當獲取鎖不成功時，會反復獲取)，但讀文件是很方便的。添加緩存的目的就是要減少數據讀取瓶頸，從而提高系統性能。
從上為個人經驗和一些資料的總結，有什麼不對的地方，或者沒有談到的地方，歡迎各位同行指正。
