我所負責的XXX.CN平臺前期由于網(wǎng)站整體運行效率低因此采用了文件緩存的方式（文件緩存就是當某個頁面第一次接受用戶訪問時將數(shù)據(jù)庫中獲取到的內(nèi)容轉(zhuǎn)化成xml文件的形式，并且存儲在服務(wù)器硬盤當中，當后面的人再來訪問時就只需要直接讀取xml緩存文件即可，減少了讀取數(shù)據(jù)庫的次數(shù)，從而達到提高網(wǎng)站運行效率的目的），但是使用了這種方式其中有一個更新數(shù)據(jù)的問題，在更新和讀取是就產(chǎn)生了并發(fā)的問題，說白了就是讀取和寫入的矛盾，當你的網(wǎng)站的訪問量達到一定程度后，產(chǎn)生這種矛盾的概率越來越大，已至于訪問者無法訪問網(wǎng)站，流失了客戶，對于我們酒店預訂平臺來說，流失的不是客戶，而是白花花的金子，這個問題已經(jīng)困撓了我許久，直到前幾天，我在坐公交時回想起前一天給面試的人打印試卷的事，突然腦子里出現(xiàn)了“復制”這個詞，并且把它擴展開想到了我們網(wǎng)站文件緩存的占用問題上，且已經(jīng)用程序的方式成功運用到我們的網(wǎng)站中，下面就講一下運行過程。

首先，我們網(wǎng)站整站的緩存方式都是依靠的DataSet的ReadXml和WriteXml的方式實現(xiàn)的，這種方式在訪問量不是很大的網(wǎng)站中是一點問題都沒有的（最大可承受的日IP估計在8000-15000左右），但是當你的網(wǎng)站日IP訪問量到達20000時，他就完全崩潰了，出現(xiàn)xml的并發(fā)占用問題日趨嚴重，于是我們就采用了文件流的形式去操作，具體代碼如下：
寫入：
        Stream s = null;
        s = File.Open(FileName, FileMode.Create, FileAccess.ReadWrite,FileShare.ReadWrite);
        BinaryFormatter b = new BinaryFormatter();
        b.Serialize(s, ds);
        s.Close();
讀取：
        Stream s = null;
        s = File.Open(FileName, FileMode.Open, FileAccess.Read);
        BinaryFormatter b = new BinaryFormatter();
        ds = (DataSet)b.Deserialize(s);
        s.Close();
這種方式在一定程度上解決了直接使用DataSet的ReadXml和WriteXml的方式帶來的問題，但是當網(wǎng)站的日訪問量達到40000或更高時，并發(fā)問題依然存在，其實存在并發(fā)的根本原因不是我們用了什么方式去讀取或者寫入（方式的不同的確在一定程度上可以解決一些問題，但根本原因沒有得到根治），而是在兩個或者更多個進程(有需要讀取的也有需要寫入的)在爭搶同一個文件時程序如何給出一個可以讓雙方滿意的方案，于是順著這個思路，我有對程序做了以下改進：

        //讀取鎖,可以讓一個文件被多個進程同時讀取，也可以保證只被一個進程改寫
        ReaderWriterLock locker = new ReaderWriterLock();//讀取鎖()

寫入：
       Stream s = null;
       try
      {
          locker.AcquireWriterLock(1500);//寫鎖定（寫入時間最大允許在1500毫秒內(nèi)完成，超時就立即退出）
          if (!File.Exists(FileName))
          {
                s = File.Create(FileName);
          }
          else
          {
               //創(chuàng)建此文件的一個副本，以供同時訪問此文件的讀取進程使用(就像打印機的復制功能)，由于使用了寫鎖定，其他的寫入進程都將轉(zhuǎn)化為讀取進程，而讀取進程是不存在并發(fā)問題的
               File.Copy(FileName,FileName.Replace(".xml","Temp.xml"),true);
               s = File.Open(FileName, FileMode.Create, FileAccess.ReadWrite,FileShare.ReadWrite);
          }
          BinaryFormatter b = new BinaryFormatter();
          b.Serialize(s, ds);
          s.Close();
       }
       finally
      {
          if(s!=null)
          {
              s.Close();
          }
          locker.ReleaseWriterLock();//釋放寫鎖定
          //這里可以加入刪除臨時文件的代碼，但不建議這樣做，我測試了下，會產(chǎn)生新的讀寫并發(fā)問題。
     }
讀取：
        Stream s = null;
        Stream sTemp = null;
        try
       {
            locker.AcquireReaderLock(1500);//讀鎖定（當所用文件被寫鎖定時超時時間為1500毫秒）
            s = File.Open(FileName, FileMode.Open, FileAccess.Read);
            BinaryFormatter b = new BinaryFormatter();
            ds = (DataSet)b.Deserialize(s);
            s.Close();
       }
       catch//這里使用catch主要是因為當讀取方法所讀的文件正在被改寫時會獲取空內(nèi)容導致異常，或者寫入超時導致文件內(nèi)容出錯時異常，或者讀鎖定超時后讀取臨時文件時剛好臨時文件被刪除時發(fā)生異常
       {
            locker.ReleaseReaderLock();//釋放鎖
            locker.AcquireReaderLock(1500);//再次鎖定
           if(File.Exists(FileName.Replace(".xml","Temp.xml")))
           {
                 //讀取副本文件
                 sTemp = File.Open(FileName.Replace(".xml","Temp.xml"), FileMode.Open, FileAccess.Read, FileShare.ReadWrite);
                 BinaryFormatter b = new BinaryFormatter();
                 ds = (DataSet)b.Deserialize(s);
                 sTemp.Close();
           }
       }
       finally
       {
           if(s!=null)
           {
               s.Close();
           }
           if(sTemp!=null)
          {
               sTemp.Close();
          }
          locker.ReleaseReaderLock();
      }
好了，以上就是最終的改進方法，想通了很簡單，就是創(chuàng)造個臨時文件而已，從這件事我覺得大家在解決一個問題時不一定老是要從純技術(shù)的角度去思考問題，之前我就想過用內(nèi)存緩存的方式去做，但總覺得，會有一個更簡單的方法的，于是使用了這種看似非常老土，而又沒有任何技術(shù)含量的方式去解決了。不管使用哪種方式，能解決問題那就是好方法。其實想想世間萬物都是相通的，只要我們發(fā)揮人類善于發(fā)掘和聯(lián)想的能力，任何問題都不是問題。

另外，我在讀操作中使用了try{}catch{},雖然進入catch流程的幾率很小，但總會影響效率，不知各位看客啊有什么更好的方法指點一下.

NET技術(shù)：Web網(wǎng)站緩存文件并發(fā)問題解決方案，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。