一、上章回顧
上一章中我們主要簡單的介紹了如何使用伺服器緩存及如何實作伺服器緩存，下面我們來通過下圖來進行詳細回顧：
1、使用者發送頁面請求，等待伺服器傳回資訊。
2、表示層通過請求業務層來通路業務資料資訊。
3、業務層在與資料通路層互動時先與伺服器緩存元件互動。
4、伺服器緩存在接收資料請求并處理的過程中判定伺服器緩存中是否存在指定的資料集緩存對象。如果存在則傳回該緩存對象，否則通過資料通路層，通路資料
庫中的資料，并把資料緩存在伺服器元件中。并傳回該查詢結果集。
5、表示層獲得資料集合後顯示。
二、摘要
本章将主要講解緩存中的過期政策及如何平衡過期這個過期政策，怎麼樣在項目中解決這樣的問題，這就是本篇要講述的内容。
三、本章大綱
1、上章回顧。
2、摘要。
3、本章大綱。
4、具體政策分析。
5、緩存過期政策方案。
6、本章總結。
7、下篇預告。
四、具體政策分析
我們我們平時使用緩存中最頭疼的問題應該就是緩存的過期的問題吧，緩存帶來的好處顯而易見，不見提高了網站應用程式的性能，同時提高了通路的速度，減少
了與資料庫互動的次數。無疑是好的方案，是以網上有很多的建議都是，能緩存的資料盡量緩存，因為緩存必定能帶來性能的提升。同時有個很大的問題始終困擾着我
們。這樣是我平時在使用緩存的過程中頭疼的問題。例如這樣的情況：
是以問題就随之而來，如何保證這個産品政策的過期性和同步性，當然我們知道産品分類一般情況下變化不大，是以我們緩存，對于資訊變化或者改變頻率較高的
資料，我們當然可以考慮每次加載的時候都緩存，等到第二次通路的時候過期這樣的方式來處理也是可以的。總之呢就是不經常改變的常用的資料資訊能緩存的一定緩
存。大家都知道2-8法則的，其實不管是什麼程式基本上都滿足這個原則。
當然Winform的程式則會比較複雜一些，可能制定的政策相對來說也不好指定。因為一般情況下來說用戶端/伺服器這樣的形式，一般的資料資訊都緩存在客戶
端，這樣伺服器壓力小一些，當然也有弊端，就是每個用戶端都是有自己的快照副本，不過由于現在硬體的速度發展迅速，是以這方面的力度可以考慮加大，顯而易
見，當資料庫中的資料發生改變後，如何通知winform程式進行緩存更新也是個重要的問題，畢竟winform程式的緩存政策與web程式的緩存方式有所不同。當然如果
說winform也是采用伺服器端緩存的話，當然也可以采用上面我們讨論的方式來實作更新政策。
下面我們來看看我了解的可操作的winform的緩存政策的更新。
當然上面隻是個人愚見，不足之處還請大家多多指點。歡迎大家拍磚，下面我們來講講各種政策的實作及優缺點。
五、緩存過期政策方案
上面我們簡單的分析了，winform與web應用程式的可能的緩存過期政策。下面我們來講講幾種可能的解決方案，當然隻是個人愚見，還請大家拍磚，這裡隻是
抛磚引玉，沒有考慮更複雜的情況。還請大家多多分享自己的經驗。
1、使用微軟提供的伺服器緩存的過期政策：
a、相對過期。舉個簡單例子就是，如果緩存對象在某個時間段内沒有被通路過，那麼該對象則過期，否則則不過期。
b、絕對過期。舉個簡單例子就是，不管緩存的對象通路沒有通路過，隻要到達設定的時間則過期。
具體的實作時，我們可以參考通過配置檔案中設定這個過期政策，例如我們參考IBatisNet中的緩存
<cacheModels>//緩存的對象清單
<cacheModel id="CacheLRU_Sys_UserRole" implementation="LRU" >//緩存的對象
<flushInterval minutes="2" />//設定過期政策
<flushOnExecute statement="Insert_Sys_UserRole"/>//重新整理的動作
<flushOnExecute statement="Update_Sys_UserRole"/>
<flushOnExecute statement="Delete_Sys_UserRole"/>
<property name="CacheSize" value="100"/>//設定緩存對象的大小
</cacheModel>
</cacheModels>
顯然通過上面提供的方式可以做到緩存對象的自動過期，但是有個情況就是不夠靈活，如果緩存對象在指定的時間段内已發生改變，那麼必須在過期時間後才能
更新緩存對象，那麼有些時候顯然不能滿足我的要求，特别是實時性的系統時這樣的緩存政策是不可行的。
2、當然上面介紹的IBatisNet中已包含設定重新整理對象時的操作的設定：
<flushOnExecute statement="Insert_Sys_UserRole"/>//重新整理的動作
<flushOnExecute statement="Update_Sys_UserRole"/>
<flushOnExecute statement="Delete_Sys_UserRole"/>
那麼展現在程式中的代碼如何書寫呢，我們來看看。
/// <summary>
/// 定義委托、用于指向更新緩存的事件
/// </summary>
/// <returns>傳回是否更新緩存</returns>
public delegate bool RefreshCache(object sender, EventArgs e);
/// <summary>
/// 維護緩存更新政策的委托集合
/// </summary>
public Dictionary<object, List<RefreshCache>> list;
那麼通過XML配置相關的引發緩存更新的事件來達到更新緩存的目的。
那麼每次委托清單中維護的對象即是所有的緩存對象的相關重新整理動作事件。通過檢測事件的執行來更新緩存對象。
具體的更新緩存的代碼如下：
public void RefreshCacheObject(object key,bool isSuccess)
{
if (!isSuccess)
return;
if (list.ContainsKey(key))
list.Remove(key);
//載入緩存
}
具體的載入緩存的代碼請參考：
網站性能優化之應用程式緩存-初篇具體的實作底層通知的代碼我還沒有想好具體的實作方式(就是比較好的方式)。想好了會把代碼貼上，當然IBatisNet已經很優秀了，我這裡也許沒有造輪子的必
要，如果誰有比較好的實作方式，那麼可以告訴我，我這裡先謝過了，我其實不是很了解底層的實作機制，是以我目前隻是采用比較笨的方式來做，雖然也實作了，但
是需要在每個事件中都要顯示的寫一部分代碼，這是我不能接受的。
3、時時更新的方式。
這裡的時時更新就是指，每次都把資料庫中的記錄全部取出來，然後循環比較結果集中的記錄與緩存的記錄是不是相同，如果不同則更新該記錄，否則跳過繼續
處理其他的資料資訊，那麼保證緩存中的記錄始終是最新的。當然這樣的方式雖然保證所有的緩存資訊是最新的，但是每次都與資料庫互動顯然不是好的解決方案，當
然有些情況下也許也是沒有辦法的事情。
最後，本文隻是抛磚引玉，希望大家多多提出寶貴意見。
六、本章總結
本文簡單的介紹了web與winform下的緩存政策，分析了幾種方式的可行性及優缺點等，還希望大家在實際的項目中根據項目的需要來指定緩存的過期政策，但
是可以肯定的是，用緩存肯定比不用緩存的性能要高。當然這裡也不是要求我們濫用緩存，也要根據資料資訊的更新頻度做一個平衡，不經常變的資料一般推薦來緩
存。畢竟伺服器中有同一副本，不但能提高通路的效率，還能減輕資料庫的通路壓力，提高并發的速度。還需要大家在實際項目中體會。
七、下篇預告
本篇并沒有把IBatis.NET中的緩存政策完整的實作，并且也沒有講到其他的一些winform的緩存政策的實作，下一篇将會詳細的講解這部分的内容，當然這些都
是本人的個人體會與總結，錯誤之處在所難免，歡迎大家提出不同意見，批評指出錯誤，謝謝大家！
作者：
IT行者-何戈洲出處：
http://www.cnblogs.com/hegezhou_hot/2007年大學畢業後便投入到計算機行業中，先後涉足（電信、電子商務、教育、醫療、工程建築、項目管理、房産）等行業,目前有比較豐富的技術及行業經驗，技術方面涉及（Java、Go、.NET、Python、設計模式、系統架構、PM管理流程、軟體工程、靈活開發、SOA、雲計算、大資料、區塊鍊、WF、SAAS等領域），結合業務可提供（EIP、ERP、HIS、B2B、B2C、B2B2C、CRM、OA、O2O等）業務及技術解決方案，随着時間的推移，目前已逐漸轉向管理方面，歡迎同行一起交流學習，個人平時愛好體育運動、音樂、旅遊等，向往豐富多彩的生活旅程。如有問題或建議，請多多賜教！
本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接，如有問題，可以通過
[email protected]聯系我，非常感謝。
其他聯系方式：
電話：13716055594
聯系人：何戈洲
微信聯系我：
