ASP.NET 缓存技术分析
緩存功能是大型網(wǎng)站設(shè)計(jì)一個(gè)很重要的部分。由數(shù)據(jù)庫(kù)驅(qū)動(dòng)的Web應(yīng)用程序，如果需要改善其性能，最好的方法是使用緩存功能。可能的情況下盡量使用緩 存，從內(nèi)存中返回?cái)?shù)據(jù)的速度始終比去數(shù)據(jù)庫(kù)查的速度快，因而可以大大提供應(yīng)用程序的性能。畢竟現(xiàn)在內(nèi)存非常便宜，用空間換取時(shí)間效率應(yīng)該是非常劃算的。尤 其是對(duì)耗時(shí)比較長(zhǎng)的、需要建立網(wǎng)絡(luò)鏈接的數(shù)據(jù)庫(kù)查詢操作等。 對(duì)于web頁(yè)面的緩存，WebForm與ASP.NET MVC有不同的語(yǔ)法。在WebForm中，?<%@ OutputCache Duration="60" VaryByParam="none" %> ?來(lái)進(jìn)行頁(yè)面緩存或者局部頁(yè)面緩存，在ASP.NET MVC中，針對(duì)Action使用Attribute進(jìn)行頁(yè)面緩存。這些都是Web框架封裝好的，而對(duì)于Web Application來(lái)講，需要緩存的不僅僅是頁(yè)面，很多時(shí)候還需要定制的去緩存一些內(nèi)容，這時(shí)候就需要用到HttpRun.Cache對(duì)象。
以下內(nèi)容轉(zhuǎn)自 ??細(xì)說(shuō) ASP.NET Cache 及其高級(jí)用法
許多做過(guò)程序性能優(yōu)化的人，或者關(guān)注過(guò)程程序性能的人，應(yīng)該都使用過(guò)各類緩存技術(shù)。 而我今天所說(shuō)的Cache是專指ASP.NET的Cache，我們可以使用HttpRuntime.Cache訪問(wèn)到的那個(gè)Cache，而不是其它的緩存技術(shù)。
Cache的基本用途
提到Cache，不得不說(shuō)說(shuō)它的主要功能：改善程序性能。
ASP.NET是一種動(dòng)態(tài)頁(yè)面技術(shù)，用ASP.NET技術(shù)做出來(lái)的網(wǎng)頁(yè)幾乎都是動(dòng)態(tài)的，所謂動(dòng)態(tài)是指：頁(yè)面的內(nèi)容會(huì)隨著不同的用戶或者持續(xù)更新的數(shù)據(jù)， 而呈現(xiàn)出不同的顯示結(jié)果。既然是動(dòng)態(tài)的，那么這些動(dòng)態(tài)的內(nèi)容是從哪里來(lái)的呢？我想絕大多數(shù)網(wǎng)站都有自己的數(shù)據(jù)源， 程序通過(guò)訪問(wèn)數(shù)據(jù)源獲取頁(yè)面所需的數(shù)據(jù)，然后根據(jù)一些業(yè)務(wù)規(guī)則的計(jì)算處理，最后變成適合頁(yè)面展示的內(nèi)容。
由于這種動(dòng)態(tài)頁(yè)面技術(shù)通常需要從數(shù)據(jù)源獲取數(shù)據(jù)，并經(jīng)過(guò)一些計(jì)算邏輯，最終變成一些HTML代碼發(fā)給客戶端顯示。而這些計(jì)算過(guò)程顯然也是有成本的。 這些處理成本最直接可表現(xiàn)為影響服務(wù)器的響應(yīng)速度，尤其是當(dāng)數(shù)據(jù)的處理過(guò)程變得復(fù)雜以及訪問(wèn)量變大時(shí)，會(huì)變得比較明顯。 另一方面，有些數(shù)據(jù)并非時(shí)刻在發(fā)生變化，如果我們可以將一些變化不頻繁的數(shù)據(jù)的最終計(jì)算結(jié)果（包括頁(yè)面輸出）緩存起來(lái)， 就可以非常明顯地提升程序的性能，緩存的最常見(jiàn)且最重要的用途就體現(xiàn)在這個(gè)方面。 這也是為什么一說(shuō)到性能優(yōu)化時(shí)，一般都將緩存擺在第一位的原因。 我今天要說(shuō)到的ASP.NET Cache也是可以實(shí)現(xiàn)這種緩存的一種技術(shù)。 不過(guò)，它還有其它的一些功能，有些是其它緩存技術(shù)所沒(méi)有的。
Cache的定義
在介紹Cache的用法前，我們先來(lái)看一下Cache的定義：（說(shuō)明：我忽略了一些意義不大的成員）
// 實(shí)現(xiàn)用于 Web 應(yīng)用程序的緩存。無(wú)法繼承此類。 public sealed class Cache : IEnumerable {// 用于 Cache.Insert(...) 方法調(diào)用中的 absoluteExpiration 參數(shù)中以指示項(xiàng)從不過(guò)期。public static readonly DateTime NoAbsoluteExpiration; // 用作 Cache.Insert(...) 或 Cache.Add(...) // 方法調(diào)用中的 slidingExpiration 參數(shù)，以禁用可調(diào)過(guò)期。 public static readonly TimeSpan NoSlidingExpiration; // 獲取或設(shè)置指定鍵處的緩存項(xiàng)。 public object this[string key] { get; set; } // 將指定項(xiàng)添加到 System.Web.Caching.Cache 對(duì)象，該對(duì)象具有依賴項(xiàng)、過(guò)期和優(yōu)先級(jí)策略 // 以及一個(gè)委托（可用于在從 Cache 移除插入項(xiàng)時(shí)通知應(yīng)用程序）。 public object Add(string key, object value, CacheDependency dependencies, DateTime absoluteExpiration, TimeSpan slidingExpiration, CacheItemPriority priority, CacheItemRemovedCallback onRemoveCallback); // 從 System.Web.Caching.Cache 對(duì)象檢索指定項(xiàng)。 // key: 要檢索的緩存項(xiàng)的標(biāo)識(shí)符。 // 返回結(jié)果: 檢索到的緩存項(xiàng)，未找到該鍵時(shí)為 null。 public object Get(string key); public void Insert(string key, object value); public void Insert(string key, object value, CacheDependency dependencies); public void Insert(string key, object value, CacheDependency dependencies, DateTime absoluteExpiration, TimeSpan slidingExpiration); // 摘要: // 向 System.Web.Caching.Cache 對(duì)象中插入對(duì)象，后者具有依賴項(xiàng)、過(guò)期和優(yōu)先級(jí)策略 // 以及一個(gè)委托（可用于在從 Cache 移除插入項(xiàng)時(shí)通知應(yīng)用程序）。 // // 參數(shù): // key: // 用于引用該對(duì)象的緩存鍵。 // // value: // 要插入緩存中的對(duì)象。 // // dependencies: // 該項(xiàng)的文件依賴項(xiàng)或緩存鍵依賴項(xiàng)。當(dāng)任何依賴項(xiàng)更改時(shí)，該對(duì)象即無(wú)效， // 并從緩存中移除。如果沒(méi)有依賴項(xiàng)，則此參數(shù)包含 null。 // // absoluteExpiration: // 所插入對(duì)象將過(guò)期并被從緩存中移除的時(shí)間。 // 如果使用絕對(duì)過(guò)期，則 slidingExpiration 參數(shù)必須為 Cache.NoSlidingExpiration。 // // slidingExpiration: // 最后一次訪問(wèn)所插入對(duì)象時(shí)與該對(duì)象過(guò)期時(shí)之間的時(shí)間間隔。如果該值等效于 20 分鐘， // 則對(duì)象在最后一次被訪問(wèn) 20 分鐘之后將過(guò)期并被從緩存中移除。如果使用可調(diào)過(guò)期，則 // absoluteExpiration 參數(shù)必須為 System.Web.Caching.Cache.NoAbsoluteExpiration。 // // priority: // 該對(duì)象相對(duì)于緩存中存儲(chǔ)的其他項(xiàng)的成本，由 System.Web.Caching.CacheItemPriority 枚舉表示。 // 該值由緩存在退出對(duì)象時(shí)使用；具有較低成本的對(duì)象在具有較高成本的對(duì)象之前被從緩存移除。 // // onRemoveCallback: // 在從緩存中移除對(duì)象時(shí)將調(diào)用的委托（如果提供）。 // 當(dāng)從緩存中刪除應(yīng)用程序的對(duì)象時(shí)，可使用它來(lái)通知應(yīng)用程序。 // // 異常: // System.ArgumentException: // 為要添加到 Cache 中的項(xiàng)設(shè)置 absoluteExpiration 和 slidingExpiration 參數(shù)。 // // System.ArgumentNullException: // key 或 value 參數(shù)為 null。 // // System.ArgumentOutOfRangeException: // 將 slidingExpiration 參數(shù)設(shè)置為小于 TimeSpan.Zero 或大于一年的等效值。 public void Insert(string key, object value, CacheDependency dependencies, DateTime absoluteExpiration, TimeSpan slidingExpiration, CacheItemPriority priority, CacheItemRemovedCallback onRemoveCallback); // 從應(yīng)用程序的 System.Web.Caching.Cache 對(duì)象移除指定項(xiàng)。 public object Remove(string key); // 將對(duì)象與依賴項(xiàng)策略、到期策略和優(yōu)先級(jí)策略 // 以及可用來(lái)在從緩存中移除項(xiàng)【之前】通知應(yīng)用程序的委托一起插入到 Cache 對(duì)象中。 // 注意：此方法受以下版本支持：3.5 SP1、3.0 SP1、2.0 SP1 public void Insert(string key, object value, CacheDependency dependencies, DateTime absoluteExpiration, TimeSpan slidingExpiration, CacheItemUpdateCallback onUpdateCallback); }ASP.NET為了方便我們?cè)L問(wèn)Cache，在HttpRuntime類中加了一個(gè)靜態(tài)屬性Cache，這樣，我們就可以在任意地方使用Cache的功 能。 而且，ASP.NET還給它增加了二個(gè)“快捷方式”：Page.Cache, HttpContext.Cache，我們通過(guò)這二個(gè)對(duì)象也可以訪問(wèn)到HttpRuntime.Cache， 注意：這三者是在訪問(wèn)同一個(gè)對(duì)象。Page.Cache訪問(wèn)了HttpContext.Cache，而HttpContext.Cache又直接訪問(wèn) HttpRuntime.Cache
Cache常見(jiàn)用法
通常，我們使用Cache時(shí)，一般只有二個(gè)操作：讀，寫。
要從Cache中獲取一個(gè)緩存項(xiàng)，我們可以調(diào)用Cache.Get(key)方法，要將一個(gè)對(duì)象放入緩存，我們可以調(diào)用Add, Insert方法。 然而，Add, Insert方法都有許多參數(shù)，有時(shí)我們或許只是想簡(jiǎn)單地放入緩存，一切接受默認(rèn)值，那么還可以調(diào)用它的默認(rèn)索引器， 我們來(lái)看一下這個(gè)索引器是如何工作的：
可以看到：讀緩存，其實(shí)是在調(diào)用Get方法，而寫緩存則是在調(diào)用Insert方法的最簡(jiǎn)單的那個(gè)重載版本。
注意了：Add方法也可以將一個(gè)對(duì)象放入緩存，這個(gè)方法有7個(gè)參數(shù)，而Insert也有一個(gè)簽名類似的重載版本， 它們有著類似的功能：將指定項(xiàng)添加到 System.Web.Caching.Cache 對(duì)象，該對(duì)象具有依賴項(xiàng)、過(guò)期和優(yōu)先級(jí)策略以及一個(gè)委托（可用于在從 Cache 移除插入項(xiàng)時(shí)通知應(yīng)用程序）。?然而，它們有一點(diǎn)小的區(qū)別：當(dāng)要加入的緩存項(xiàng)已經(jīng)在Cache中存在時(shí)，Insert將會(huì)覆蓋原有的緩存項(xiàng)目，而Add則不會(huì)修改原有緩存項(xiàng)。
也就是說(shuō)：如果您希望某個(gè)緩存項(xiàng)目一旦放入緩存后，就不要再被修改，那么調(diào)用Add確實(shí)可以防止后來(lái)的修改操作。 而調(diào)用Insert方法，則永遠(yuǎn)會(huì)覆蓋已存在項(xiàng)（哪怕以前是調(diào)用Add加入的）。
從另一個(gè)角度看，Add的效果更像是 static readonly 的行為，而Insert的效果則像 static 的行為。
注意：我只是說(shuō)【像】，事實(shí)上它們比一般的static成員有著更靈活的用法。
由于緩存項(xiàng)可以讓我們隨時(shí)訪問(wèn)，看起來(lái)確實(shí)有點(diǎn)static成員的味道，但它們有著更高級(jí)的特性，比如： 緩存過(guò)期（絕對(duì)過(guò)期，滑動(dòng)過(guò)期），緩存依賴（依賴文件，依賴其它緩存項(xiàng)），移除優(yōu)先級(jí)，緩存移除前后的通知等等。 后面我將會(huì)分別介紹這四大類特性。
Cache類的特點(diǎn)
Cache類有一個(gè)很難得的優(yōu)點(diǎn)，用MSDN上的說(shuō)話就是：
此類型是線程安全的。
為什么這是個(gè)難得的優(yōu)點(diǎn)呢？因?yàn)樵?net中，絕大多數(shù)類在實(shí)現(xiàn)時(shí)，都只是保證靜態(tài)類型的方法是線程安全， 而不考慮實(shí)例方法是線程安全。這也算是一條基本的.NET設(shè)計(jì)規(guī)范原則。
對(duì)于那些類型，MSDN通常會(huì)用這樣的話來(lái)描述：
此類型的公共靜態(tài)（在 Visual Basic 中為 Shared）成員是線程安全的。但不能保證任何實(shí)例成員是線程安全的。
所以，這就意味著我們可以在任何地方讀寫Cache都不用擔(dān)心Cache的數(shù)據(jù)在多線程環(huán)境下的數(shù)據(jù)同步問(wèn)題。 多線程編程中，最復(fù)雜的問(wèn)題就是數(shù)據(jù)的同步問(wèn)題，而Cache已經(jīng)為我們解決了這些問(wèn)題。
不過(guò)我要提醒您：ASP.NET本身就是一個(gè)多線程的編程模型，所有的請(qǐng)求是由線程池的線程來(lái)處理的。 通常，我們?cè)诙嗑€程環(huán)境中為了解決數(shù)據(jù)同步問(wèn)題，一般是采用鎖來(lái)保證數(shù)據(jù)同步， 自然地，ASP.NET也不例外，它為了解決數(shù)據(jù)的同步問(wèn)題，內(nèi)部也是采用了鎖。
說(shuō)到這里，或許有些人會(huì)想：既然只一個(gè)Cache的靜態(tài)實(shí)例，那么這種鎖會(huì)不會(huì)影響并發(fā)？
答案是肯定的，有鎖肯定會(huì)在一定程度上影響并發(fā)，這是沒(méi)有辦法的事情。
然而，ASP.NET在實(shí)現(xiàn)Cache時(shí)，會(huì)根據(jù)CPU的個(gè)數(shù)創(chuàng)建多個(gè)緩存容器，盡量可能地減小沖突， 以下就是Cache創(chuàng)建的核心過(guò)程：
說(shuō)明：CacheInternal是個(gè)內(nèi)部用的包裝類，Cache的許多操作都要由它來(lái)完成。
在上面的代碼中，numSingleCaches的計(jì)算過(guò)程很重要，如果上面代碼不容易理解，那么請(qǐng)看我下面的示例代碼：?
static void Main() {for( uint i = 1; i <= 20; i++ ) ShowCount(i); } static void ShowCount(uint numProcessCPUs) { int numSingleCaches = 1; for( numProcessCPUs -= 1; numProcessCPUs > 0; numProcessCPUs = numProcessCPUs >> 1 ) { numSingleCaches = numSingleCaches << 1; } Console.Write(numSingleCaches + ","); }程序?qū)?huì)輸出：
1,2,4,4,8,8,8,8,16,16,16,16,16,16,16,16,32,32,32,32
CacheMultiple的構(gòu)造函數(shù)如下：
internal CacheMultiple(CacheCommon cacheCommon, int numSingleCaches) : base(cacheCommon) {this._cacheIndexMask = numSingleCaches - 1; this._caches = new CacheSingle[numSingleCaches]; for (int i = 0; i < numSingleCaches; i++) { this._caches[i] = new CacheSingle(cacheCommon, this, i); } } 現(xiàn)在您應(yīng)該明白了吧：CacheSingle其實(shí)是ASP.NET內(nèi)部使用的緩存容器，多個(gè)CPU時(shí)，它會(huì)創(chuàng)建多個(gè)緩存容器。
在寫入時(shí)，它是如何定位這些容器的呢？請(qǐng)繼續(xù)看代碼：
說(shuō)明：參數(shù)中的hashCode是直接調(diào)用我們傳的key.GetHashCode() ，GetHashCode是由Object類定義的。
所以，從這個(gè)角度看，雖然ASP.NET的Cache只有一個(gè)HttpRuntime.Cache靜態(tài)成員，但它的內(nèi)部卻可能會(huì)包含多個(gè)緩存容器， 這種設(shè)計(jì)可以在一定程度上減少并發(fā)的影響。
不管如何設(shè)計(jì)，在多線程環(huán)境下，共用一個(gè)容器，沖突是免不了的。如果您只是希望簡(jiǎn)單的緩存一些數(shù)據(jù)， 不需要Cache的許多高級(jí)特性，那么，可以考慮不用Cache 。 比如：可以創(chuàng)建一個(gè)Dictionary或者Hashtable的靜態(tài)實(shí)例，它也可以完成一些基本的緩存工作， 不過(guò)，我要提醒您：您要自己處理多線程訪問(wèn)數(shù)據(jù)時(shí)的數(shù)據(jù)同步問(wèn)題。
順便說(shuō)一句：Hashtable.Synchronized(new Hashtable())也是一個(gè)線程安全的集合，如果想簡(jiǎn)單點(diǎn)，可以考慮它。
接下來(lái)，我們來(lái)看一下Cache的高級(jí)特性，這些都是Dictionary或者Hashtable不能完成的。
緩存項(xiàng)的過(guò)期時(shí)間
ASP.NET支持二種緩存項(xiàng)的過(guò)期策略：絕對(duì)過(guò)期和滑動(dòng)過(guò)期。
1. 絕對(duì)過(guò)期，這個(gè)容易理解：就是在緩存放入Cache時(shí)，指定一個(gè)具體的時(shí)間。當(dāng)時(shí)間到達(dá)指定的時(shí)間的時(shí)，緩存項(xiàng)自動(dòng)從Cache中移除。
2. 滑動(dòng)過(guò)期：某些緩存項(xiàng)，我們可能只希望在有用戶在訪問(wèn)時(shí)，就盡量保留在緩存中，只有當(dāng)一段時(shí)間內(nèi)用戶不再訪問(wèn)該緩存項(xiàng)時(shí)，才移除它， 這樣可以優(yōu)化內(nèi)存的使用，因?yàn)檫@種策略可以保證緩存的內(nèi)容都是【很熱門】的。 操作系統(tǒng)的內(nèi)存以及磁盤的緩存不都是這樣設(shè)計(jì)的嗎？而這一非常有用的特性，Cache也為我們準(zhǔn)備好了，只要在將緩存項(xiàng)放入緩存時(shí)， 指定一個(gè)滑動(dòng)過(guò)期時(shí)間就可以實(shí)現(xiàn)了。
以上二個(gè)選項(xiàng)分別對(duì)應(yīng)Add, Insert方法中的DateTime absoluteExpiration, TimeSpan slidingExpiration這二個(gè)參數(shù)。
注意：這二個(gè)參數(shù)都是成對(duì)使用的，但不能同時(shí)指定它們?yōu)橐粋€(gè)【有效】值，最多只能一個(gè)參數(shù)值有效。 當(dāng)不使用另一個(gè)參數(shù)項(xiàng)時(shí)，請(qǐng)用Cache類定義二個(gè)static readonly字段賦值。
這二個(gè)參數(shù)比較簡(jiǎn)單，我就不多說(shuō)了，只說(shuō)一句：如果都使用Noxxxxx這二個(gè)選項(xiàng)，那么緩存項(xiàng)就一直保存在緩存中。（或許也會(huì)被移除）
緩存項(xiàng)的依賴關(guān)系 - 依賴其它緩存項(xiàng)
ASP.NET Cache有個(gè)很強(qiáng)大的功能，那就是緩存依賴。一個(gè)緩存項(xiàng)可以依賴于另一個(gè)緩存項(xiàng)。 以下示例代碼創(chuàng)建了二個(gè)緩存項(xiàng)，且它們間有依賴關(guān)系。首先請(qǐng)看頁(yè)面代碼：
<body><p>Key1 的緩存內(nèi)容：= HttpRuntime.Cache["key1"] </p> <hr /> <form action="CacheDependencyDemo.aspx" method="post"> <input type="submit" name="SetKey1Cache" value="設(shè)置Key1的值" /> <input type="submit" name="SetKey2Cache" value="設(shè)置Key2的值" /> </form> </body>頁(yè)面后臺(tái)代碼：
public partial class CacheDependencyDemo : System.Web.UI.Page { [SubmitMethod(AutoRedirect=true)] private void SetKey1Cache() { SetKey2Cache(); CacheDependency dep = new CacheDependency(null, new string[] { "key2" }); HttpRuntime.Cache.Insert("key1", DateTime.Now.ToString(), dep, Cache.NoAbsoluteExpiration, Cache.NoSlidingExpiration); } [SubmitMethod(AutoRedirect=true)] private void SetKey2Cache() { HttpRuntime.Cache.Insert("key2", Guid.NewGuid().ToString()); } }當(dāng)運(yùn)行這個(gè)示例頁(yè)面時(shí)，運(yùn)行結(jié)果如下圖所示， 點(diǎn)擊按鈕【設(shè)置Key1的值】時(shí)，將會(huì)出現(xiàn)緩存項(xiàng)的內(nèi)容（左圖）。點(diǎn)擊按鈕【設(shè)置Key2的值】時(shí)，此時(shí)將獲取不到緩存項(xiàng)的內(nèi)容（右圖）。
根據(jù)結(jié)果并分析代碼，我們可以看出，在創(chuàng)建Key1的緩存項(xiàng)時(shí)，我們使用了這種緩存依賴關(guān)系：
CacheDependency dep = new CacheDependency(null, new string[] { "key2" });所以，當(dāng)我們更新Key2的緩存項(xiàng)時(shí)，Key1的緩存就失效了（不存在）。
不要小看了這個(gè)示例。的確，僅看這幾行示例代碼，或許它們實(shí)在是沒(méi)有什么意義。 那么，我就舉個(gè)實(shí)際的使用場(chǎng)景來(lái)說(shuō)明它的使用價(jià)值。
上面這幅圖是我寫的一個(gè)小工具。在示意圖中，左下角是一個(gè)緩存表CacheTable，它由一個(gè)叫Table1BLL的類來(lái)維護(hù)。 CacheTable的數(shù)據(jù)來(lái)源于Table1，由Table1.aspx頁(yè)面顯示出來(lái)。 同時(shí)，ReportA, ReportB的數(shù)據(jù)也主要來(lái)源于Table1，由于Table1的訪問(wèn)幾乎絕大多數(shù)都是讀多寫少，所以，我將Table1的數(shù)據(jù)緩存起來(lái)了。 而且，ReportA, ReportB這二個(gè)報(bào)表采用GDI直接畫出（由報(bào)表模塊生成，可認(rèn)是Table1BLL的上層類），鑒于這二個(gè)報(bào)表的瀏覽次數(shù)較多且數(shù)據(jù)源是讀多寫少， 因此，這二個(gè)報(bào)表的輸出結(jié)果，我也將它們緩存起來(lái)。
在這個(gè)場(chǎng)景中，我們可以想像一下：如果希望在Table1的數(shù)據(jù)發(fā)生修改后，如何讓二個(gè)報(bào)表的緩存結(jié)果失效？
讓Table1BLL去通知那二個(gè)報(bào)表模塊，還是Table1BLL去直接刪除二個(gè)報(bào)表的緩存？
其實(shí)，不管是選擇前者還是后者，當(dāng)以后還需要在Table1的CacheTable上做其它的緩存實(shí)現(xiàn)時(shí)（可能是其它的新報(bào)表）， 那么，勢(shì)必都要修改Table1BLL，那絕對(duì)是個(gè)失敗的設(shè)計(jì)。 這也算是模塊間耦合的所帶來(lái)的惡果。
幸好，ASP.NET Cache支持一種叫做緩存依賴的特性，我們只需要讓Table1BLL公開(kāi)它緩存CacheTable的KEY就可以了（假設(shè)KEY為 CacheTableKey）， 然后，其它的緩存結(jié)果如果要基于CacheTable，設(shè)置一下對(duì)【CacheTableKey】的依賴就可以實(shí)現(xiàn)這樣的效果：?當(dāng)CacheTable更新后，被依賴的緩存結(jié)果將會(huì)自動(dòng)清除。這樣就徹底地解決了模塊間的緩存數(shù)據(jù)依賴問(wèn)題。
緩存項(xiàng)的依賴關(guān)系 - 文件依賴
我希望在用戶修改了配置文件后，程序能立刻以最新的參數(shù)運(yùn)行，而且不用重啟網(wǎng)站。
首先，我要說(shuō)明一點(diǎn)，雖然解決方案與Cache的文件依賴有關(guān)，但還需與緩存的移除通知配合使用才能完美的解決問(wèn)題。 為了便于內(nèi)容的安排，我先使用Cache的文件依賴來(lái)簡(jiǎn)單的實(shí)現(xiàn)一個(gè)粗糙的版本，在本文的后續(xù)部分再來(lái)完善這個(gè)實(shí)現(xiàn)。
先來(lái)看個(gè)粗糙的版本。假如我的網(wǎng)站中有這樣一個(gè)配置參數(shù)類型：
/// <summary> /// 模擬網(wǎng)站所需的運(yùn)行參數(shù) /// </summary> public class RunOptions {public string WebSiteUrl; public string UserName; }我可以將它配置在這樣一個(gè)XML文件中：
<?xml version="1.0" encoding="utf-8"?> <RunOptions xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <WebSiteUrl>http://www.cnblogs.com/fish-li</WebSiteUrl> <UserName>fish li</UserName> </RunOptions>再來(lái)一個(gè)用于顯示運(yùn)行參數(shù)的頁(yè)面：?
<body><p>WebSiteUrl: = WebSiteApp.RunOptions.WebSiteUrl </p> <p>UserName: = WebSiteApp.RunOptions.UserName </p> </body>下面的代碼就可以實(shí)現(xiàn)：在XML修改后，瀏覽頁(yè)面就能立即看到最新的參數(shù)值：
public static class WebSiteApp {private static readonly string RunOptionsCacheKey = Guid.NewGuid().ToString(); public static RunOptions RunOptions { get { // 首先嘗試從緩存中獲取運(yùn)行參數(shù) RunOptions options = HttpRuntime.Cache[RunOptionsCacheKey] as RunOptions; if( options == null ) { // 緩存中沒(méi)有，則從文件中加載 string path = HttpContext.Current.Server.MapPath("~/App_Data/RunOptions.xml"); options = RwConfigDemo.XmlHelper.XmlDeserializeFromFile<RunOptions>(path, Encoding.UTF8); // 把從文件中讀到的結(jié)果放入緩存，并設(shè)置與文件的依賴關(guān)系。 CacheDependency dep = new CacheDependency(path); // 如果您的參數(shù)較復(fù)雜，與多個(gè)文件相關(guān)，那么也可以使用下面的方式，傳遞多個(gè)文件路徑。 //CacheDependency dep = new CacheDependency(new string[] { path }); HttpRuntime.Cache.Insert(RunOptionsCacheKey, options, dep); } return options; } } }注意：這里仍然是在使用CacheDependency，只是我們現(xiàn)在是給它的構(gòu)造函數(shù)的第一個(gè)參數(shù)傳遞要依賴的文件名。
在即將結(jié)束對(duì)緩存的依賴介紹之前，還要補(bǔ)充二點(diǎn)：
1. CacheDependency還支持【嵌套】，即：CacheDependency的構(gòu)造函數(shù)中支持傳入其它的CacheDependency實(shí)例，這樣可以構(gòu)成一種非常復(fù)雜的樹(shù)狀依賴關(guān)系。
2. 緩存依賴的對(duì)象還可以是SQL SERVER，具體可參考SqlCacheDependency
緩存項(xiàng)的移除優(yōu)先級(jí)
緩存的做法有很多種，一個(gè)靜態(tài)變量也可以稱為是一個(gè)緩存。一個(gè)靜態(tài)的集合就是一個(gè)緩存的容器了。 我想很多人都用Dictionary，List，或者Hashtable做過(guò)緩存容器，我們可以使用它們來(lái)保存各種數(shù)據(jù)，改善程序的性能。 一般情況下，如果我們直接使用這類集合去緩存各類數(shù)據(jù)，那么，那些數(shù)據(jù)所占用的內(nèi)存將不會(huì)被回收，哪怕它們的使用機(jī)會(huì)并不是很多。 當(dāng)緩存數(shù)據(jù)越來(lái)越多時(shí)，它們所消耗的內(nèi)存自然也會(huì)越來(lái)越多。那么，能不能在內(nèi)存不充足時(shí)，釋放掉一些訪問(wèn)不頻繁的緩存項(xiàng)呢？
這個(gè)問(wèn)題也確實(shí)是個(gè)較現(xiàn)實(shí)的問(wèn)題。雖然，使用緩存會(huì)使用程序運(yùn)行更快，但是，我們數(shù)據(jù)會(huì)無(wú)限大，不可能統(tǒng)統(tǒng)緩存起來(lái)， 畢竟，內(nèi)存空間是有限的。因此，我們可以使用前面所說(shuō)的基于一段時(shí)間內(nèi)不再訪問(wèn)就 刪除的策略來(lái)解決這個(gè)問(wèn)題。 然而，在我們編碼時(shí)，根本不知道我們的程序會(huì)運(yùn)行在什么配置標(biāo)準(zhǔn)的計(jì)算機(jī)上，因此，根本不可能會(huì)對(duì)內(nèi)存的大小作出任何假設(shè)， 此時(shí)，我們可能會(huì)希望當(dāng)緩存占用過(guò)多的內(nèi)存時(shí)，且當(dāng)內(nèi)存不夠時(shí)，能自動(dòng)移除一些不太重要的緩存項(xiàng)，這或許也比較有意義。
對(duì)于這個(gè)需求，在.net framework提供了二種解決辦法，一種是使用WeakReference類，另一種是使用Cache 。 不過(guò)，既然我們是在使用ASP.NET，選擇Cache當(dāng)然會(huì)更方便。 在Cache的Add, Insert方法的某些重載版本中，可以指定緩存項(xiàng)的保存優(yōu)先級(jí)策略，由參數(shù)CacheItemPriority priority來(lái)傳入。 其中，CacheItemPriority是一個(gè)枚舉類型，它包含了如下枚舉值：
// 指定 Cache 對(duì)象中存儲(chǔ)的項(xiàng)的相對(duì)優(yōu)先級(jí)。 public enum CacheItemPriority {// 在服務(wù)器釋放系統(tǒng)內(nèi)存時(shí)，具有該優(yōu)先級(jí)級(jí)別的緩存項(xiàng)最有可能被從緩存刪除。Low = 1, // 在服務(wù)器釋放系統(tǒng)內(nèi)存時(shí)，具有該優(yōu)先級(jí)級(jí)別的緩存項(xiàng)比分配了 CacheItemPriority.Normal // 優(yōu)先級(jí)的項(xiàng)更有可能被從緩存刪除。 BelowNormal = 2, // 在服務(wù)器釋放系統(tǒng)內(nèi)存時(shí)，具有該優(yōu)先級(jí)級(jí)別的緩存項(xiàng)很有可能被從緩存刪除， // 其被刪除的可能性僅次于具有 CacheItemPriority.Low // 或 CacheItemPriority.BelowNormal 優(yōu)先級(jí)的那些項(xiàng)。這是默認(rèn)選項(xiàng)。 Normal = 3, // 緩存項(xiàng)優(yōu)先級(jí)的默認(rèn)值為 CacheItemPriority.Normal。 Default = 3, // 在服務(wù)器釋放系統(tǒng)內(nèi)存時(shí)，具有該優(yōu)先級(jí)級(jí)別的緩存項(xiàng)被刪除的可能性 // 比分配了 CacheItemPriority.Normal 優(yōu)先級(jí)的項(xiàng)要小。 AboveNormal = 4, // 在服務(wù)器釋放系統(tǒng)內(nèi)存時(shí)，具有該優(yōu)先級(jí)級(jí)別的緩存項(xiàng)最不可能被從緩存刪除。 High = 5, // 在服務(wù)器釋放系統(tǒng)內(nèi)存時(shí)，具有該優(yōu)先級(jí)級(jí)別的緩存項(xiàng)將不會(huì)被自動(dòng)從緩存刪除。 // 但是，具有該優(yōu)先級(jí)級(jí)別的項(xiàng)會(huì)根據(jù)項(xiàng)的絕對(duì)到期時(shí)間或可調(diào)整到期時(shí)間與其他項(xiàng)一起被移除。 NotRemovable = 6, }說(shuō)明：當(dāng)我們調(diào)用Cache的Add, Insert方法時(shí)，如果不指定CacheItemPriority選項(xiàng)，最終使用Normal所代表的優(yōu)先級(jí)。 如果我們希望將某個(gè)可能不太重要的數(shù)據(jù)放入緩存時(shí)，可以指定優(yōu)先級(jí)為L(zhǎng)ow或者BelowNormal。 如果想讓緩存項(xiàng)在內(nèi)存不足時(shí)，也不會(huì)被移除（除非到期或者依賴項(xiàng)有改變），可使用NotRemovable。
顯然，我們可以使用這個(gè)特性來(lái)控制緩存對(duì)內(nèi)存壓力的影響。 其它的緩存方案，如static Collection + WeakReference也較難實(shí)現(xiàn)這樣靈活的控制。
緩存項(xiàng)的移除通知
ASP.NET Cache與一些static變量所實(shí)現(xiàn)的緩存效果并不相同，它的緩存項(xiàng)是可以根據(jù)一些特定的條件失效的，那些失效的緩存將會(huì)從內(nèi)存中移除。 雖然，某些移除條件并不是由我們的代碼直接解發(fā)的，但ASP.NET還是提供一種方法讓我們可以在緩存項(xiàng)在移除時(shí)，能通知我們的代碼。
注意哦：ASP.NET Cache支持移除【前】通知 和 移除【后】通知二種通知方式。
我們可以在調(diào)用Add, Insert方法時(shí)，通過(guò)參數(shù)onRemoveCallback傳遞一個(gè)CacheItemRemovedCallback類型的委托，以便在移除指定的緩存項(xiàng)時(shí)， 能夠通知我們。這個(gè)委托的定義如下：
/// <summary> /// 定義在從 System.Web.Caching.Cache 移除緩存項(xiàng)時(shí)通知應(yīng)用程序的回調(diào)方法。 /// </summary> /// <param name="key">從緩存中移除的鍵（當(dāng)初由Add, Insert傳入的）。</param> /// <param name="value">與從緩存中移除的鍵關(guān)聯(lián)的緩存項(xiàng)（當(dāng)初由Add, Insert傳入的）。</param> /// <param name="reason">從緩存移除項(xiàng)的原因。 </param> public delegate void CacheItemRemovedCallback(string key, object value, CacheItemRemovedReason reason); // 指定從 System.Web.Caching.Cache 對(duì)象移除項(xiàng)的原因。 public enum CacheItemRemovedReason { // 該項(xiàng)是通過(guò)指定相同鍵的 Cache.Insert(System.String,System.Object) // 方法調(diào)用或 Cache.Remove(System.String) 方法調(diào)用從緩存中移除的。 Removed = 1, // 從緩存移除該項(xiàng)的原因是它已過(guò)期。 Expired = 2, // 之所以從緩存中移除該項(xiàng)，是因?yàn)橄到y(tǒng)要通過(guò)移除該項(xiàng)來(lái)釋放內(nèi)存。 Underused = 3, // 從緩存移除該項(xiàng)的原因是與之關(guān)聯(lián)的緩存依賴項(xiàng)已更改。 DependencyChanged = 4, } 委托的各個(gè)參數(shù)的含義以及移除原因，在注釋中都有明確的解釋，我也不再重復(fù)了。
我想：有很多人知道Cache的Add, Insert方法有這個(gè)參數(shù)，也知道有這個(gè)委托，但是，它們有什么用呢？ 在后面的二個(gè)小節(jié)中，我將提供二個(gè)示例來(lái)演示這一強(qiáng)大的功能。
通常，我們會(huì)以下面這種方式從Cache中獲取結(jié)果：
RunOptions options = HttpRuntime.Cache[RunOptionsCacheKey] as RunOptions; if( options == null ) { // 緩存中沒(méi)有，則從文件中加載 // .................................. HttpRuntime.Cache.Insert(RunOptionsCacheKey, options, dep); } return options;這其實(shí)也是一個(gè)慣用法了：先嘗試從緩存中獲取，如果沒(méi)有，則從數(shù)據(jù)源中加載，并再次放入緩存。
為什么會(huì)在訪問(wèn)Cache時(shí)返回null呢？答案無(wú)非就是二種原因：1. 根本沒(méi)有放入Cache，2. 緩存項(xiàng)失效被移除了。
這種寫法本身是沒(méi)有問(wèn)題，可是，如果從數(shù)據(jù)源中加載數(shù)據(jù)的時(shí)間較長(zhǎng)，情況會(huì)怎樣呢？
顯然，會(huì)影響后面第一次的訪問(wèn)請(qǐng)求。您有沒(méi)有想過(guò)，如果緩存項(xiàng)能一直放在Cache中，那不就可以了嘛。 是的，通常來(lái)說(shuō)，只要您在將一個(gè)對(duì)象放入Cache時(shí)，不指定過(guò)期時(shí)間，不指定緩存依賴，且設(shè)置為永不移除，那么對(duì)象確實(shí)會(huì)一直在Cache中， 可是，過(guò)期時(shí)間和緩存依賴也很有用哦。如何能二者兼得呢？
與 CacheItemRemovedReason 枚舉不同，此枚舉不包含 Removed 或 Underused 值。可更新的緩存項(xiàng)是不可移除的，因而絕不會(huì)被 ASP.NET 自動(dòng)移除，即使需要釋放內(nèi)存也是如此。
再一次提醒：有時(shí)我們確實(shí)需要緩存失效這個(gè)特性，但是，緩存失效后會(huì)被移除。 雖然我們可以讓后續(xù)的請(qǐng)求在獲取不到緩存數(shù)據(jù)時(shí)，從數(shù)據(jù)源中加載，也可以在CacheItemRemovedCallback回調(diào)委托中， 重新加載緩存數(shù)據(jù)到Cache中，但是在數(shù)據(jù)的加載過(guò)程中，Cache并不包含我們所期望的緩存數(shù)據(jù)，如果加載時(shí)間越長(zhǎng)，這種【空缺】效果也會(huì)越明顯。?這樣會(huì)影響（后續(xù)的）其它請(qǐng)求的訪問(wèn)。為了保證讓我們所期望的緩存數(shù)據(jù)能夠一直存在于Cahce中，且仍有失效機(jī)制，我們可以使用【移除前通知】功能。
巧用緩存項(xiàng)的移除通知 實(shí)現(xiàn)【延遲操作】
我看過(guò)一些ASP.NET的書(shū)，也看過(guò)一些人寫的關(guān)于Cache方面的文章，基本上，要么是一帶而過(guò)，要么只是舉個(gè)毫無(wú)實(shí)際意義的示例。 可惜啊，這么強(qiáng)大的特性，我很少見(jiàn)到有人把它用起來(lái)。
今天，我就舉個(gè)有實(shí)際意義的示例，再現(xiàn)Cache的強(qiáng)大功能！
我有這樣一個(gè)頁(yè)面，可以讓用戶調(diào)整（上下移動(dòng)）某個(gè)項(xiàng)目分支記錄的上線順序：
當(dāng)用戶需要調(diào)整某條記錄的位置時(shí)，頁(yè)面會(huì)彈出一個(gè)對(duì)話框，要求輸入一個(gè)調(diào)整原因，并會(huì)發(fā)郵件通知所有相關(guān)人員。
由于界面的限制，一次操作（點(diǎn)擊上下鍵頭）只是將一條記錄移動(dòng)一個(gè)位置，當(dāng)要對(duì)某條記錄執(zhí)行跨越多行移動(dòng)時(shí)，必須進(jìn)行多次移動(dòng)。 考慮到操作的方便性以及不受重復(fù)郵件的影響，程序需要實(shí)現(xiàn)這樣一個(gè)需求： 頁(yè)面只要求輸入一次原因便可以對(duì)一條記錄執(zhí)行多次移動(dòng)操作，并且不要多次發(fā)重復(fù)郵件，而且要求將最后的移動(dòng)結(jié)果在郵件中發(fā)出來(lái)。
這個(gè)需求很合理，畢竟誰(shuí)都希望操作簡(jiǎn)單。
那么如何實(shí)現(xiàn)這個(gè)需求呢？這里要從二個(gè)方面來(lái)實(shí)現(xiàn)，首先，在頁(yè)面上我們應(yīng)該要完成這個(gè)功能，對(duì)一條記錄只彈一次對(duì)話框。 由于頁(yè)面與服務(wù)端的交互全部采用Ajax方式進(jìn)行（不刷新），狀態(tài)可以采用JS變量來(lái)維持，所以這個(gè)功能在頁(yè)面中是很容易實(shí)現(xiàn)。 再來(lái)看一下服務(wù)端，由于服務(wù)端并沒(méi)有任何狀態(tài)，當(dāng)然也可以由頁(yè)面把它的狀態(tài)傳給服務(wù)端，但是，哪次操作是最后一次呢？ 顯然，這是無(wú)法知道的，最后只能修改需求，如果用戶在2分鐘之內(nèi)不再操作某條記錄時(shí)，便將最近一次操作視為最后一次操作。
基于新的需求，程序必須記錄用戶的最近一次操作，以便在2分鐘不操作后，發(fā)出一次郵件，但要包含第一次輸入的原因， 還應(yīng)包含最后的修改結(jié)果哦。
該怎么實(shí)現(xiàn)這個(gè)需求呢？ 我立即就想到了ASP.NET Cache，因?yàn)槲伊私馑?#xff0c;知道它能幫我完成這個(gè)功能。下面我來(lái)說(shuō)說(shuō)在服務(wù)端是如何實(shí)現(xiàn)的。
整個(gè)實(shí)現(xiàn)的思路是：
1. 客戶端頁(yè)面還是每次將記錄的RowGuid, 調(diào)整方向，調(diào)整原因，這三個(gè)參數(shù)發(fā)到服務(wù)端。
2. 服務(wù)端在處理完順序調(diào)整操作后，將要發(fā)送的郵件信息Insert到Cache中，同時(shí)提供slidingExpiration和onRemoveCallback參數(shù)。
3. 在CacheItemRemovedCallback回調(diào)委托中，忽略CacheItemRemovedReason.Removed的通知，如果是其它的通知，則發(fā)郵件。
為了便于理解，我特意為大家準(zhǔn)備了一個(gè)示例。整個(gè)示例由三部分組成：一個(gè)頁(yè)面，一個(gè)JS文件，服務(wù)端代碼。先來(lái)看頁(yè)面代碼：?
頁(yè)面的顯示效果如下：
處理頁(yè)面中二個(gè)按鈕的JS代碼如下：?
// 用戶輸入的調(diào)整記錄的原因 var g_reason = null;$(function(){$("#btnMoveUp").click( function() { MoveRec(-1); } ); $("#btnMoveDown").click( function() { MoveRec(1); } ); }); function MoveRec(direction){ if( ~~($("#spanSequence").text()) + direction < 0 ){ alert("已經(jīng)不能上移了。"); return; } if( g_reason == null ){ g_reason = prompt("請(qǐng)輸入調(diào)整記錄順序的原因：", "由于什么什么原因，我要調(diào)整..."); if( g_reason == null ) return; } $.ajax({ url: "/AjaxDelaySendMail/MoveRec.fish", data: { RowGuid: $("#spanRowGuid").text(), Direction: direction, Reason: g_reason }, type: "POST", dataType: "text", success: function(responseText){ $("#spanSequence").text(responseText); } }); }說(shuō)明：在服務(wù)端，我使用了我在【用Asp.net寫自己的服務(wù)框架】那篇博客中提供的服務(wù)框架， 服務(wù)端的全部代碼是這個(gè)樣子的：（注意代碼中的注釋）?
/// <summary> /// 移動(dòng)記錄的相關(guān)信息。 /// </summary> public class MoveRecInfo {public string RowGuid; public int Direction; public string Reason; } [MyService] public class AjaxDelaySendMail { [MyServiceMethod] public int MoveRec(MoveRecInfo info) { // 這里就不驗(yàn)證從客戶端傳入的參數(shù)了。實(shí)際開(kāi)發(fā)中這個(gè)是必須的。 // 先來(lái)調(diào)整記錄的順序，示例程序沒(méi)有數(shù)據(jù)庫(kù)，就用Cache來(lái)代替。 int sequence = 0; int.TryParse(HttpRuntime.Cache[info.RowGuid] as string, out sequence); // 簡(jiǎn)單地示例一下調(diào)整順序。 sequence += info.Direction; HttpRuntime.Cache[info.RowGuid] = sequence.ToString(); string key = info.RowGuid +"_DelaySendMail"; // 這里我不直接發(fā)郵件，而是把這個(gè)信息放入Cache中，并設(shè)置2秒的滑過(guò)過(guò)期時(shí)間，并指定移除通知委托 // 將操作信息放在緩存，并且以覆蓋形式放入，這樣便可以實(shí)現(xiàn)保存最后狀態(tài)。 // 注意：這里我用Insert方法。 HttpRuntime.Cache.Insert(key, info, null, Cache.NoAbsoluteExpiration, TimeSpan.FromMinutes(2.0), CacheItemPriority.NotRemovable, MoveRecInfoRemovedCallback); return sequence; } private void MoveRecInfoRemovedCallback(string key, object value, CacheItemRemovedReason reason) { if( reason == CacheItemRemovedReason.Removed ) return; // 忽略后續(xù)調(diào)用HttpRuntime.Cache.Insert()所觸發(fā)的操作 // 能運(yùn)行到這里，就表示是肯定是緩存過(guò)期了。 // 換句話說(shuō)就是：用戶2分鐘再也沒(méi)操作過(guò)了。 // 從參數(shù)value取回操作信息 MoveRecInfo info = (MoveRecInfo)value; // 這里可以對(duì)info做其它的處理。 // 最后發(fā)一次郵件。整個(gè)延遲發(fā)郵件的過(guò)程就處理完了。 MailSender.SendMail(info); } }為了能讓JavaScript能直接調(diào)用C#中的方法，還需要在web.config中加入如下配置：
<httpHandlers><add path="*.fish" verb="*" validate="false" type="MySimpleServiceFramework.AjaxServiceHandler"/> </httpHandlers>好了，示例代碼就是這些。如果您有興趣，可以在本文的結(jié)尾處下載這些示例代碼，自己親自感受一下利用Cache實(shí)現(xiàn)的【延遲處理】的功能。
其實(shí)這種【延遲處理】的功能是很有用的，比如還有一種適用場(chǎng)景：有些數(shù)據(jù)記錄可能需要頻繁更新，如果每次更新都去寫數(shù)據(jù)庫(kù)，肯定會(huì)對(duì)數(shù)據(jù)庫(kù)造成一定的壓力，?但由于這些數(shù)據(jù)也不是特別重要，因此，我們可以利用這種【延遲處理】來(lái)將寫數(shù)據(jù)庫(kù)的時(shí)機(jī)進(jìn)行合并處理， 最終我們可以實(shí)現(xiàn)：將多次的寫入變成一次或者少量的寫入操作，我稱這樣效果為：延遲合并寫入
這里我就對(duì)數(shù)據(jù)庫(kù)的延遲合并寫入提 供一個(gè)思路：將需要寫入的數(shù)據(jù)記錄放入Cache，調(diào)用Insert方法并提供slidingExpiration和onRemoveCallback參 數(shù)， 然后在CacheItemRemovedCallback回調(diào)委托中，模仿我前面的示例代碼，將多次變成一次。不過(guò)，這樣可能會(huì)有一個(gè)問(wèn)題：如果數(shù)據(jù)是一 直在修改，那么就一直不會(huì)寫入數(shù)據(jù)庫(kù)。 最后如果網(wǎng)站重啟了，數(shù)據(jù)可能會(huì)丟失。如果擔(dān)心這個(gè)問(wèn)題，那么，可以在回調(diào)委托中，遇到CacheItemRemovedReason.Removed 時(shí)，使用計(jì)數(shù)累加的方式，當(dāng)?shù)竭_(dá)一定數(shù)量后， 再寫入數(shù)據(jù)庫(kù)。比如：遇到10次CacheItemRemovedReason.Removed我就寫一次數(shù)據(jù)庫(kù)，這樣就會(huì)將原來(lái)需要寫10次的數(shù)據(jù)庫(kù)操 作變成一次了。 當(dāng)然了，如果是其它移除原因，寫數(shù)據(jù)庫(kù)總是必要的。注意：對(duì)于金額這類敏感的數(shù)據(jù)，絕對(duì)不要使用這種方法。
再補(bǔ)充二點(diǎn)：
1. 當(dāng)CacheItemRemovedCallback回調(diào)委托被調(diào)用時(shí)，緩存項(xiàng)已經(jīng)不在Cache中了。
2. 在CacheItemRemovedCallback回調(diào)委托中，我們還可以將緩存項(xiàng)重新放入緩存。
有沒(méi)有想過(guò)：這種設(shè)計(jì)可以構(gòu)成一個(gè)循環(huán)？如果再結(jié)合參數(shù)slidingExpiration便可實(shí)現(xiàn)一個(gè)定時(shí)器的效果。
關(guān)于緩存的失效時(shí)間，我要再提醒一點(diǎn)：通過(guò)absoluteExpiration, slidingExpiration參數(shù)所傳入的時(shí)間，當(dāng)緩存時(shí)間生效時(shí)，緩存對(duì)象并不會(huì)立即移除，?ASP.NET Cache大約以20秒的頻率去檢查這些已過(guò)時(shí)的緩存項(xiàng)。
巧用緩存項(xiàng)的移除通知 實(shí)現(xiàn)【自動(dòng)加載配置文件】
在本文的前部分的【文件依賴】小節(jié)中，有一個(gè)示例演示了：當(dāng)配置文件更新后，頁(yè)面可以顯示最新的修改結(jié)果。 在那個(gè)示例中，為了簡(jiǎn)單，我直接將配置參數(shù)放在Cache中，每次使用時(shí)再?gòu)腃ache中獲取。 如果配置參數(shù)較多，這種做法或許也會(huì)影響性能，畢竟配置參數(shù)并不會(huì)經(jīng)常修改，如果能直接訪問(wèn)一個(gè)靜態(tài)變量就能獲取到，應(yīng)該會(huì)更快。 通常，我們可能會(huì)這樣做：
private static RunOptions s_RunOptions;public static RunOptions RunOptions {// s_RunOptions 的初始化放在Init方法中了，會(huì)在Global.asax的Application_Start事件中調(diào)用。get { return s_RunOptions; } } public static RunOptions LoadRunOptions() { string path = Path.Combine(AppDataPath, "RunOptions.xml"); return RwConfigDemo.XmlHelper.XmlDeserializeFromFile<RunOptions>(path, Encoding.UTF8); }但是，這種做法有一缺點(diǎn)就是：不能在配置文件更新后，自動(dòng)加載最新的配置結(jié)果。
為了解決這個(gè)問(wèn)題，我們可以使用Cache提供的文件依賴以及移除通知功能。 前面的示例演示了移除后通知功能，這里我再演示一下移除前通知功能。
說(shuō)明：事實(shí)上，完成這個(gè)功能，可以仍然使用移除后通知，只是移除前通知我還沒(méi)有演示，然而，這里使用移除前通知并沒(méi)有顯示它的獨(dú)有的功能。
下面的代碼演示了在配置文件修改后，自動(dòng)更新運(yùn)行參數(shù)的實(shí)現(xiàn)方式：（注意代碼中的注釋）
private static int s_RunOptionsCacheDependencyFlag = 0;public static RunOptions LoadRunOptions() {string path = Path.Combine(AppDataPath, "RunOptions.xml"); // 注意啦：訪問(wèn)文件是可能會(huì)出現(xiàn)異常。不要學(xué)我，我寫的是示例代碼。 RunOptions options = RwConfigDemo.XmlHelper.XmlDeserializeFromFile<RunOptions>(path, Encoding.UTF8); int flag = System.Threading.Interlocked.CompareExchange(ref s_RunOptionsCacheDependencyFlag, 1, 0); // 確保只調(diào)用一次就可以了。 if( flag == 0 ) { // 讓Cache幫我們盯住這個(gè)配置文件。 CacheDependency dep = new CacheDependency(path); HttpRuntime.Cache.Insert(RunOptionsCacheKey, "Fish Li", dep, Cache.NoAbsoluteExpiration, Cache.NoSlidingExpiration, RunOptionsUpdateCallback); } return options; } public static void RunOptionsUpdateCallback( string key, CacheItemUpdateReason reason, out object expensiveObject, out CacheDependency dependency, out DateTime absoluteExpiration, out TimeSpan slidingExpiration) { // 注意哦：在這個(gè)方法中，不要出現(xiàn)【未處理異常】，否則緩存對(duì)象將被移除。 // 說(shuō)明：這里我并不關(guān)心參數(shù)reason，因?yàn)槲腋揪蜎](méi)有使用過(guò)期時(shí)間 // 所以，只有一種原因：依賴的文件發(fā)生了改變。 // 參數(shù)key我也不關(guān)心，因?yàn)檫@個(gè)方法是【專用】的。 expensiveObject = "http://www.cnblogs.com/fish-li/"; dependency = new CacheDependency(Path.Combine(AppDataPath, "RunOptions.xml")); absoluteExpiration = Cache.NoAbsoluteExpiration; slidingExpiration = Cache.NoSlidingExpiration; // 重新加載配置參數(shù) s_RunOptions = LoadRunOptions(); }改動(dòng)很小，只是LoadRunOptions方法做了修改了而已，但是效果卻很酷。
還記得我在上篇博客【在.net中讀寫config文件的各種方法】的結(jié)尾處留下來(lái)的問(wèn)題嗎？ 這個(gè)示例就是我的解決方案。
文件監(jiān)視技術(shù)的選擇
對(duì)于文件監(jiān)視，我想有人或許會(huì)想到FileSystemWatcher。正好我就來(lái)說(shuō)說(shuō)關(guān)于【文件監(jiān)視技術(shù)】的選擇問(wèn)題。
說(shuō)明，本文所有結(jié)論均為我個(gè)人的觀點(diǎn)，僅供參考。
這個(gè)組件，早在做WinForm開(kāi)發(fā)時(shí)就用過(guò)了，對(duì)它也是印象比較深的。
它有一個(gè)包裝不好的地方是：事件會(huì)重復(fù)發(fā)出。比如：一次文件的保存操作，它卻引發(fā)了二次事件。
什么，你不信？ 正好，我還準(zhǔn)備了一個(gè)示例程序。
說(shuō)明：圖片中顯示了發(fā)生過(guò)二次事件，但我只是在修改了文件后，做了一次保存操作而已。 本文的結(jié)尾處有我的示例程序，您可以自己去試一下。這里為了方便，還是貼出相關(guān)代碼：?
private void Form1_Shown(object sender, EventArgs e) {this.fileSystemWatcher1.Path = Environment.CurrentDirectory; this.fileSystemWatcher1.Filter = "RunOptions.xml"; this.fileSystemWatcher1.NotifyFilter = System.IO.NotifyFilters.LastWrite; this.fileSystemWatcher1.EnableRaisingEvents = true; } private void fileSystemWatcher1_Changed(object sender, System.IO.FileSystemEventArgs e) { string message = string.Format("{0} {1}.", e.Name, e.ChangeType); this.listBox1.Items.Add(message); }對(duì)于這個(gè)類的使用，只想說(shuō)一點(diǎn)：會(huì)引發(fā)的事件很多，因此一定要注意過(guò)濾。以下引用MSDN的一段說(shuō)明：
Windows 操作系統(tǒng)在 FileSystemWatcher 創(chuàng)建的緩沖區(qū)中通知組件文件發(fā)生更改。如果短時(shí)間內(nèi)有很多更改，則緩沖區(qū)可能會(huì)溢出。這將導(dǎo)致組件失去對(duì)目錄更改的跟蹤，并且它將只提供一般性通知。使用 InternalBufferSize 屬性來(lái)增加緩沖區(qū)大小的開(kāi)銷較大，因?yàn)樗鼇?lái)自無(wú)法換出到磁盤的非頁(yè)面內(nèi)存，所以應(yīng)確保緩沖區(qū)大小適中（盡量小，但也要有足夠大小以便不會(huì)丟失任何文件更改 事件）。若要避免緩沖區(qū)溢出，請(qǐng)使用 NotifyFilter 和 IncludeSubdirectories 屬性，以便可以篩選掉不想要的更改通知。
幸運(yùn)的是，ASP.NET Cache并沒(méi)有使用這個(gè)組件，我們不用擔(dān)心文件依賴而引發(fā)的重復(fù)操作問(wèn)題。 它直接依賴于webengine.dll所提供的API，因此，建議在ASP.NET應(yīng)用程序中，優(yōu)先使用Cache所提供的文件依賴功能。
各種緩存方案的共存
ASP.NET Cache是一種緩存技術(shù)，然而，我們?cè)贏SP.NET程序中還可以使用其它的緩存技術(shù)， 這些不同的緩存也各有各自的長(zhǎng)處。由于ASP.NET Cache不能提供對(duì)外訪問(wèn)能力，因此，它不可能取代以memcached為代表的分布式緩存技術(shù)， 但它由于是不需要跨進(jìn)程訪問(wèn)，效率也比分布式緩存的速度更快。如果將ASP.NET Cache設(shè)計(jì)成【一級(jí)緩存】， 分布式緩存設(shè)計(jì)成【二級(jí)緩存】，就像CPU的緩存那樣，那么將能同時(shí)利用二者的所有的優(yōu)點(diǎn)，實(shí)現(xiàn)更完美的功能以及速度。
其實(shí)緩存是沒(méi)有一個(gè)明確定義的技術(shù)，一個(gè)static變量也是一個(gè)緩存，一個(gè)static集合就是一個(gè)緩存容器了。 這種緩存與ASP.NET Cache相比起來(lái)，顯然static變量的訪問(wèn)速度會(huì)更快，如果static集合不是設(shè)計(jì)得很差的話， 并發(fā)的沖突也可能會(huì)比ASP.NET Cache小，也正是因?yàn)檫@一點(diǎn)，static集合也有著廣泛的使用。 然而，ASP.NET Cache的一些高級(jí)功能，如：過(guò)期時(shí)間，緩存依賴（包含文件依賴），移除通知，也是static集合不具備的。 因此，合理地同時(shí)使用它們，會(huì)讓程序有著最好的性能，也同時(shí)擁有更強(qiáng)大的功能。
轉(zhuǎn)載于:https://www.cnblogs.com/xhety/p/3986782.html
總結(jié)
以上是生活随笔為你收集整理的ASP.NET 缓存技术分析的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 民生银行李易峰信用卡礼品：峰享月双倍积分
- 下一篇： 信用卡还最低还款额会影响信用吗？