php高併發狀態下檔案的讀寫

2021-09-07 02:19:09 字數 3236 閱讀 3110

背景

1、對於pv不高或者說併發數不是很大的應用,不用考慮這些,一般的檔案操作方法完全沒有問題

2、如果併發高,在我們對檔案進行讀寫操作時,很有可能多個程序對進一檔案進行操作,如果這時不對檔案的訪問進行相應的獨佔,就容易造成資料丟失

對於這樣的問題,一般的解決方案

1、當一程序對檔案進行操作時,首先對其它進行加鎖

2、這裡只有該程序有權對檔案進行讀取,其它程序如果現在讀,是完全沒有問題,但如果這時有程序試圖想對其進行更新,會遭到操作拒絕,

3、先前對檔案進行加鎖的程序這時如果對檔案的更新操作完畢,這就釋放獨佔的標識,這時檔案又恢復到了可更改的狀態

4、接下來同理,如果那個程序在操作檔案時,檔案沒有加鎖,這時,它就可以放心大膽的對檔案進行鎖定,獨自享用

所以一般的方案會是

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

if (flock($fp, lock_ex)) else

fclose($fp);

但在php中,flock似乎工作的不是那麼好!在多併發情況下,似乎是經常獨佔資源,不即時釋放,或者是根本不釋放,造成死鎖,從而使伺服器的cpu占用很高,甚至有時候會讓伺服器徹底死掉。好像在很多linux/unix系統中,都會有這樣的情況發生。

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

那麼就沒有解決方案了嗎?其實也不是這樣的。如果flock()我們使用得當,完全可能解決死鎖的問題。當然如果不考慮使用flock()函式,也同樣會有很好的解決方案來解決我們的問題。

方案一:對檔案進行加鎖時,設定乙個超時時間.

大致實現如下:

if($fp = fopen($filename, 'a'))  while ((!$canwrite) && ((microtime()-$starttime) < 1000));

if ($canwrite)

fclose($fp);

}

超時設定為1ms,如果這裡時間內沒有獲得鎖,就反覆獲得,直接獲得到對檔案操作權為止,當然。如果超時限制已到,就必需馬上退出,讓出鎖讓其它程序來進行操作。

方案二:不使用flock函式,借用臨時檔案來解決讀寫衝突的問題

大致原理如下:

1、將需要更新的檔案copy乙份到我們的臨時檔案目錄,將檔案最後修改時間儲存到乙個變數,並為這個臨時檔案取乙個隨機的,不容易重複的檔名

2、當對這個臨時檔案進行更新後,再檢測原檔案的最後更新時間和先前所儲存的時間是否一致

3、如果最後一次修改時間一致,就將所修改的臨時檔案重新命名到原檔案,為了確保檔案狀態同步更新,所以需要清除一下檔案狀態

4、但是,如果最後一次修改時間和先前所儲存的一致,這說明在這期間,原檔案已經被修改過,這時,需要把臨時檔案刪除,然後返回false,說明檔案這時有其它程序在進行操作

大致實現**如下:

$dir_fileopen = "tmp";

function randomid()

function cfopen($filename, $mode) while(file_exists($tempfilename));

if (file_exists($filename)) else

$fp = fopen($tempfilename, $mode);

return $fp ? array($fp, $filename, $id, @filemtime($filename)) : false;

}function cfwrite($fp,$string)

function cfclose($fp, $debug = "off") else

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、不需要排隊。(影響快)方案三

在設計快取系統時,一般我們不會採用方案三。因為方案三的分析程式和寫入程式是不同步的,在寫的時間,完全不考慮到時候分析的難度,只管寫的行了。試想一 下,如我們在更新乙個快取時,如果也採用隨機檔案讀寫法,那麼在讀快取時似乎會增加很多流程。但採取方案

一、二就完全不一樣,雖然寫的時間需要等待(當獲 取鎖不成功時,會反覆獲取),

但讀檔案是很方便的。新增快取的目的就是要減少資料讀取瓶頸,從而提高系統效能。

讀 寫鎖的實現和應用(高併發狀態下的map實現)

程式中涉及到對一些共享資源的讀和寫操作,且寫操作沒有讀操作那麼頻繁。在沒有寫操作的時候,兩個執行緒同時讀乙個資源沒有任何問題,所以應該允許多個執行緒能在同時讀取共享資源。但是如果有乙個執行緒想去寫這些共享資源,就不應該再有其它執行緒對該資源進行讀或寫 譯者注 也就是說 讀 讀能共存,讀 寫不能共存,...

讀 寫鎖的實現和應用(高併發狀態下的map實現)

程式中涉及到對一些共享資源的讀和寫操作,且寫操作沒有讀操作那麼頻繁。在沒有寫操作的時候,兩個執行緒同時讀乙個資源沒有任何問題,所以應該允許多個執行緒能在同時讀取共享資源。但是如果有乙個執行緒想去寫這些共享資源,就不應該再有其它執行緒對該資源進行讀或寫 譯者注 也就是說 讀 讀能共存,讀 寫不能共存,...

binlog在併發狀態下的記錄

前兩天看binlog發現個奇怪的地方 對於position靠後的記錄,timestamp卻比之前的記錄還要小。當時覺得大概和併發有關係 後來做了個實驗 開兩個session 對於session1 begin insert into t1 values 1 insert into t1 values ...