對于日IP不高或者說并發(fā)數(shù)不是很大的應用，一般不用考慮這些！用一般的文件操作方法完全沒有問題。但如果并發(fā)高，在我們對文件進行讀寫操作時，很有可能多個進程對進一文件進行操作，如果這時不對文件的訪問進行相應的獨占，就容易造成數(shù)據(jù)丟失。
例如：一個在線聊天室（這里假定把聊天內容寫入文件），在同一時刻，用戶A和用戶B都要操作數(shù)據(jù)保存文件，首先是A打開了文件，然后更新里面的數(shù)據(jù)，但這里B也正好也打開了同一個文件，也準備更新里面的數(shù)據(jù)。當A把寫好的文件保存時，這里其實B已經(jīng)打開了文件。但當B再把文件保存回去時，這里已經(jīng)造成了數(shù)據(jù)的丟失，因為這里B用戶完全不知道它所打開的文件在它對其進行更改時，A用戶也更改了這個文件，所以最后B用戶保存更改時，用戶A的更新就被會丟失。
對于這樣的問題，一般的解決方案時當一進程對文件進行操作時，首先對其它進行加鎖，意味著這里只有該進程有權對文件進行讀取，其它進程如果現(xiàn)在讀，是完全沒有問題，但如果這時有進程試圖想對其進行更新，會遭到操作拒絕，先前對文件進行加鎖的進程這時如果對文件的更新操作完畢，這就釋放獨占的標識，這時文件又恢復到了可更改的狀態(tài)。接下來同理，如果那個進程在操作文件時，文件沒有加鎖，這時，它就可以放心大膽的對文件進行鎖定，獨自享用。
一般的方案會是：

方案二：不使用flock函數(shù)，借用臨時文件來解決讀寫沖突的問題。大致原理如下：
（1）將需要更新的文件考慮一份到我們的臨時文件目錄，將文件最后修改時間保存到一個變量，并為這個臨時文件取一個隨機的，不容易重復的文件名。
（2）當對這個臨時文件進行更新后，再檢測原文件的最后更新時間和先前所保存的時間是否一致。
（3）如果最后一次修改時間一致，就將所修改的臨時文件重命名到原文件，為了確保文件狀態(tài)同步更新，所以需要清除一下文件狀態(tài)。
（4）但是，如果最后一次修改時間和先前所保存的一致，這說明在這期間，原文件已經(jīng)被修改過，這時，需要把臨時文件刪除，然后返回false,說明文件這時有其它進程在進行操作。
實現(xiàn)代碼如下：

方案三：對操作的文件進行隨機讀寫，以降低并發(fā)的可能性。
在對用戶訪問日志進行記錄時，這種方案似乎被采用的比較多。先前需要定義一個隨機空間，空間越大，并發(fā)的的可能性就越小，這里假設隨機讀寫空間為[1-500],那么我們的日志文件的分布就為log1~到log500不等。每一次用戶訪問，都將數(shù)據(jù)隨機寫到log1~log500之間的任一文件。在同一時刻，有2個進程進行記錄日志，A進程可能是更新的log32文件，而B進程呢？則此時更新的可能就為log399.要知道，如果要讓B進程也操作log32,概率基本上為1/500,差不多約等于零。在需要對訪問日志進行分析時，這里我們只需要先將這些日志合并，再進行分析即可。使用這種方案來記錄日志的一個好處時，進程操作排隊的可能性比較小，可以使進程很迅速的完成每一次操作。

方案四：將所有要操作的進程放入一個隊列中。然后專門放一個服務完成文件操作。隊列中的每一個排除的進程相當于第一個具體的操作，所以第一次我們的服務只需要從隊列中取得相當于具體操作事項就可以了，如果這里還有大量的文件操作進程，沒關系，排到我們的隊列后面即可，只要愿意排，隊列的多長都沒關系。

對于以前幾種方案，各有各的好處！大致可能歸納為兩類：
（1）需要排隊（影響慢）比如方案一、二、四
（2）不需要排隊。（影響快）方案三
在設計緩存系統(tǒng)時，一般我們不會采用方案三。因為方案三的分析程序和寫入程序是不同步的，在寫的時間，完全不考慮到時候分析的難度，只管寫的行了。試想一下，如我們在更新一個緩存時，如果也采用隨機文件讀寫法，那么在讀緩存時似乎會增加很多流程。但采取方案一、二就完全不一樣，雖然寫的時間需要等待（當獲取鎖不成功時，會反復獲?。?，但讀文件是很方便的。添加緩存的目的就是要減少數(shù)據(jù)讀取瓶頸，從而提高系統(tǒng)性能。
從上為個人經(jīng)驗和一些資料的總結，有什么不對的地方，或者沒有談到的地方，歡迎各位同行指正。