999视频在线观看,欧美日韩在线视频一区二区三区,国产内射老熟女aaaa

主頁 > 知識庫 > 全面剖析.Net環境下的緩存技術

全面剖析.Net環境下的緩存技術

一、概念
1.1 緩存能解決的問題
· 性能——將相應數據存儲起來以避免數據的重復創建、處理和傳輸，可有效提高性能。比如將不改變的數據緩存起來，例如國家列表等，這樣能明顯提高web程序的反應速度；

· 穩定性——同一個應用中，對同一數據、邏輯功能和用戶界面的多次請求時經常發生的。當用戶基數很大時，如果每次請求都進行處理，消耗的資源是很大的浪費，也同時造成系統的不穩定。例如，web應用中，對一些靜態頁面的呈現內容進行緩存能有效的節省資源，提高穩定性。而緩存數據也能降低對數據庫的訪問次數，降低數據庫的負擔和提高數據庫的服務能力；

· 可用性——有時，提供數據信息的服務可能會意外停止，如果使用了緩存技術，可以在一定時間內仍正常提供對最終用戶的支持，提高了系統的可用性。

1.2 理解狀態
在深入介紹緩存技術之前，需要對狀態有一個認識，因為緩存可以說是狀態管理的框架。理解狀態的含義和它的一些特性——比如生存期和生存范圍——對決定是否緩存和選擇合適的緩存技術有很大幫助。狀態是指一些數據，在應用系統某個時間點上，數據的狀態和條件。這些數據可能是永久性的存儲在數據庫中，可能是只在內存里停留一會，也可能是按照某個邏輯存活（比如多長時間后釋放），它的應用范圍可能是所有用戶可訪問，可能是單個用戶有權限；

1.2.1 狀態的生存期
生存期是指數據保持有效性的時間區間，也就是從創建到移除的時間間隔。通常的生存期有以下幾種：

·永久狀態Permanent State——應用程序使用的永久數據；

·進程狀態Process State——只在進程周期內有效；

·會話狀態Session State——和特定的用戶會話有關；

·消息狀態Message State——處理某個消息的時間內有效；

1.2.2 狀態的范圍
狀態的范圍指對該狀態有訪問權限的物理或邏輯范圍。

·物理范圍指可以被訪問到的狀態數據存放的物理位置，通常包括：

1、組織Organization——在一個組織內的所有應用程序可以訪問狀態數據；

2、場Farm——在應用場范圍內的任何機器上都可以訪問；

3、機器Machine——單個機器范圍內可以訪問；

4、進程Process——進程內的訪問許可；

5、應用域AppDomain——應用程序域內的訪問許可。

·邏輯范圍指可訪問狀態數據的邏輯范圍，常見的有：

1、應用程序Application；

2、業務流程Business Process；

3、角色Role；

4、用戶User；

1.2.3 狀態數據的陳舊
緩存的狀態數據只是主數據（Master State Data）的快照，由于數據源可能被修改，所以狀態數據就有會陳舊的特性。合理利用此特性和將數據陳舊的負面影響最小化是緩存狀態數據的一個重要任務。你可以以一下方式定義數據的陳舊依據：

·主數據更改的可能性——隨著時間的推進，主數據更改的可能是否大大增加？安照這一點來決定緩存狀態數據的陳舊；

·更改的相關性——主數據更新時，緩存的狀態數據不相應更新是不是造成影響系統的使用？比如，更改系統的外觀風格并不會對業務造成很大影響。

1.2.4 狀態數據陳舊的容忍度
緩存狀態數據的陳舊對業務流程的影響稱為容忍度，應用系統的可以為不能容忍(No Tolerance)和一定程度的容忍(some Tolerance)，前者必須和主數據同步更新，后者允許一定時間或一定范圍的陳舊，判斷標準就是對業務流程的影響度。

1.2.5 理解狀態數據的轉換過程
狀態的另一個屬性是在不同階段的表現形式。在數據庫中存儲的是原始格式的數據，業務流程中的是處理過的數據，給最終用戶呈現的則是另外的形式。如下表所示：

當決定緩存數據時，應該考慮緩存哪個階段（哪種形式）的狀態數據。以下方針有助于你做決定：

· 當業務邏輯可以容忍緩存數據的陳舊時就緩存原始數據；原始數據可以緩存在數據庫訪問組件和服務代理中；

·緩存處理過的數據以減少處理時間和資源；處理過的數據可以緩存在業務邏輯組件和服務接口中。

·當需要呈現的數據量很大并且控件的呈現時間很長時，緩存呈現數據（比如包含大數據量的Treeview控件）。這種數據應該被緩存在UI控件中。

1.3 為什么要緩存數據
在應用程序中緩存數據有以下好處：

·減少交互的通訊量——緩存數據能有效減少在進程和機器間的傳輸量；

·降低系統中的處理量——減少處理次數；

·降低需要做的磁盤訪問次數——比如緩存在內存中的數據。

1.4 數據應該被緩存在哪里
緩存數據只是一份主數據的拷貝，它可能在內存中或以不同的表現形式保存在硬盤上，也就是說，離說句的使用者越近越好。所以，除了考慮要緩存哪些數據以外，數據緩存在哪里也是一個主要的考量點。這個問題分為以下兩個范圍：

1、存儲類型Storage Type——數據可用的物理存儲位置；

2、層間的架構元素（Layered architecture elements）——數據可用的邏輯存儲位置。

1.4.1 存儲類型
緩存有很多實現方法，所有這些可以被分為兩類，基于內存的緩存和基于磁盤的緩存：

1、內存駐留緩存——包含在內存中臨時存儲數據的所有實現方法，通常在以下情況下使用：

a) 應用程序頻繁使用同樣的數據；

b) 應用程序需要經常獲取數據；

通過將數據保留在內存中，你可以有效降低昂貴的磁盤訪問操作，也可以通過將數據保留在使用者進程中來最大程度的減少跨進程的數據傳輸。

2、磁盤駐留緩存——這種技術包含所有使用磁盤作為存儲介質的緩存技術，如文件和數據庫。在以下情況下基于磁盤的緩存是很有效的：

a) 處理大數據量時；

b) 應用服務提供的數據可能并不是總能使用（比如離線的情況）；

c) 緩存的數據必須能在進程回收和機器重啟的情況下保持有效；

通過緩存處理過的數據，你可以有效降低數據處理的負擔，同時可減少數據交互的代價。

1.4.2 架構間元素
應用程序中的每個邏輯層的組件都會處理數據，當使用這些組件進行工作時，你需要考慮哪些數據可以被緩存起來，還有以哪種方式進行緩存會對程序的整體性能和可用性有幫助，以上的這些元素都可以緩存相應的數據。當然，要考慮的遠不止這些。

1.5 實施緩存時的考慮
當設計一個緩存方案時，不但要考慮緩存哪些數據、數據緩存到哪里，還有其它的因素需要考慮。

1.5.1 格式和訪問模式
當決定是否緩存一個對象時，關于數據的格式和訪問機制，你需要考慮三個主要問題：

1、線程安全——當緩存的內容可以被多個線程訪問時，使用某種鎖定機制來保證數據不會被兩個線程同時操作；

2、序列化——將一個對象緩存時，需要將它序列化以便保存，所以包緩存的對象必須支持序列化；

3、規格化緩存數據——緩存數據時，相對于要使用的數據格式而言，要保證數據的格式是優化過的。

1.5.2 內容加載
在使用緩存數據前，必須將數據加載到緩存中，有兩種機制來加載數據：

·提前加載Proactive Load——使用這種方式時，你提前將所有的狀態數據加載到緩存中，可能在應用程序或線程啟動時進行，然后在應用程序或線程的生存期內一直緩存；

·動態加載Reactive Load——或稱反應式加載，當使用這種方法時，在應用程序請求數據時取到數據，并且將它緩存起來以備后續使用。

1.5.3 過期策略
另外一個關鍵因素是如何保持緩存數據和主數據（文件或數據庫或其他的應用程序資源）的一致性，你可以定義過期策略來決定緩存中的內容，如已經緩存的時間或者收到其他資源的通知。

1.5.4 安全性
當緩存數據時，需要非常清楚緩存中數據的潛在安全威脅。緩存中的數據可能會被別的進程訪問或修改，而此進程對主數據是沒有權限的。原因是當數據存儲在原始位置時，有相應的安全機制來保護它，當數據被帶出傳統的安全邊界時，需要有同等的安全機制。

1.5.5 管理
當你緩存數據時，應用系統需要的維護工作加大了。在發布應用程序時，需要配置相應的屬性，比如緩存的大小限制和清除策略。同時要使用某種機制來監控緩存的效率（比如事件日志和性能計數器）

1.6 小結
第一節內容簡單介紹了緩存技術中的概念、緩存數據的原因和方案、優勢、實施緩存方案時的考慮等基本內容。現在你對緩存中涉及的內容有了一個大致了解，下面著重介紹可用的緩存技術。

二、緩存技術
本節將介紹以下技術：

使用Asp.Net緩存；

使用Remoting Singleton緩存；

使用內存映射文件；

使用SQL Server緩存；

使用靜態變量緩存；

使用Asp.net 會話狀態(Session State)；

使用Asp.net客戶端緩存和狀態；

使用Internet Explorer緩存。

2.1 Asp.net緩存
將常用的數據保存在內存中對asp的開發人員來說并不陌生，Session對象和Application對象提供鍵值對來緩存數據，Session對象保存和單個用戶有關的數據，Application對象可保留和應用程序有關的數據，每個用戶都可以訪問。

在Asp.net中，提供了專門用于緩存數據的Cache對象，它的應用范圍是應用程序域。生存期是和應用程序緊密相關的，每當應用程序啟動的時候就重新創建Cache對象。它域Application對象的主要區別就是提供了專門用于緩存管理的特性，比如依賴和過期策略。

你可以使用Cache對象和它的屬性來實現高級的緩存功能，同時可以利用Asp.net Cache來對客戶端輸出的響應內容進行緩存。關于Asp.net中的緩存技術，有以下內容要介紹：

2.1.1 編程緩存Programmatic Caching
Cache對象定義在System.Web.Caching命名空間，可以使用HttpContext類的Cache屬性或Page對象的Cache屬性來得到Cache的引用，Cache對象除了存儲鍵值對以外，還可以存儲.net框架的對象。下面介紹相應的依賴和過期策略。

2.1.1.1 依賴和過期策略
當向緩存中加數據時，可以指定它的依賴關系來實現在某些情況下強制移除它。可用的方案包括以下幾種：

·文件依賴（File Dependency）——當硬盤上的某個（某些）文件更改時，強制移除緩存數據；如：

CacheDependency cDependency = new

CacheDependency(Server.MapPath("authors.xml"));

Cache.Insert("CachedItem", item, cDependency);

·鍵值依賴（Key Dependency）——指定緩存中的某個數據項更改時移除。如：

// Create a cache entry.

Cache["key1"] = "Value 1";

// Make key2 dependent on key1.

String[] dependencyKey = new String[1];

dependencyKey[0] = "key1";

CacheDependency dependency = new CacheDependency(null, dependencyKey);

Cache.Insert("key2", "Value 2", dependency);

·基于時間的過期策略——按照預先定義的時間策略來使數據失效，可以是絕對時間（如某個日期的18:00）也可以是相對現在的相對時間。如：

/// Absolute expiration

Cache.Insert("CachedItem", item, null, DateTime.Now.AddSeconds(5),Cache.NoSlidingExpiration);

/// Sliding expiration

Cache.Insert("CachedItem", item, null, Cache.NoAbsoluteExpiration,

TimeSpan.FromSeconds(5));

使用太短和太長的過期時間都不行，不是造成用不上的緩存數據，就是緩存了陳舊的數據并加重了緩存負擔，所以可以使用高并發的測試來決定過期時間的最佳值。

·另外有個問題就是如何實現對數據庫的依賴，這就要求實現自己的通知機制，當數據庫數據改變時能夠通知你的緩存數據改變。

由于數據會過期，所以當使用緩存中的數據時，必須檢查數據的有效性。如以下代碼：

string data = (string)Cache["MyItem"];

if (data == null)

{

data = GetData();

Cache.Insert("MyItem", data);

}

DoSomeThingWithData(data);

依賴和過期策略指定了緩存中數據的移除方式，有時候你可能需要在移除發生時做一些工作，這能靠寫代碼來實現這一點，這就是我們要講到的。

2.1.1.2 使用緩存回調（Cache Callback）
你可以定義回調，這樣當移除自動發生時，你可以不移除它或者使用新的數據來替換它。如：

CacheItemRemovedCallback onRemove = new CacheItemRemovedCallback(this.RemovedCallback);

Cache.Insert("CachedItem",

item,

null,

Cache.NoAbsoluteExpiration,

Cache.NoSlidingExpiration,

CacheItemPriority.Default,

onRemove);

// Implement the function to handle the expiration of the cache.

public void RemovedCallback(string key, object value, CacheItemRemovedReason r)

{

// Test whether the item is expired, and reinsert it into the cache.

if (r == CacheItemRemovedReason.Expired)

{

// Reinsert it into the cache again.

CacheItemRemovedCallback onRemove = null;

onRemove = new CacheItemRemovedCallback(this.RemovedCallback);

Cache.Insert(key,

value,

null,

Cache.NoAbsoluteExpiration,

Cache.NoSlidingExpiration,

CacheItemPriority.Default,

onRemove);

}

}

2.1.1.3 對緩存項使用優先級
當運行應用程序的服務器內存不足時，會自動清除緩存中的數據，稱為“清除scavenging”。此時，Cache對象根據緩存項的優先級來決定先移除哪些緩存數據，你可以在代碼中指定緩存項的優先級。參看MSDN中“CacheItemPriority 枚舉”，如：

Cache.Insert("DSN", connectionString, null, d, t, CacheItemPriority.High, onRemove);

2.1.1.4 刷新數據（清除緩存）
沒有直接的方法來刷新Asp.net的輸出緩存，但是有替代方法（設置所有數據失效），比如：

Response.Cache.SetExpires(DateTime.Now)

這可以清除緩存，但頁面上并不立刻體現出來，直到最初的緩存期結束，比如：

%@ OutputCache Duration="10" VaryByParam="none" %>指令指定的緩存只會在10秒后才清除。通常并不需要清除所有緩存項，你只要重新加載數據更新緩存就夠了。

2.1.2 輸出緩存（Output Cache）
你可以使用兩種方式的輸出緩存來緩存需要傳輸和顯示到客戶端瀏覽器上的數據——頁面輸出緩存（Page Output Cache）和頁面片斷緩存（Page Fragment Cache）。當整個頁面相對變化較少時，可以緩存整個頁面；如果只是頁面的一部分經常變化，可以使用片斷緩存。

2.1.2.1 頁面輸出緩存
Page Output Caching將對頁面請求的響應放入緩存中，后續對此頁面的請求將直接從緩存中得到信息而不是重建此頁面。可以通過添加Page指令（高級別，聲明實現）來實現，也可以使用HTTPCachePolicy類來實現（低級別，程序實現）。本指南不打算介紹技術細節，只給出如何更好使用的指南和最佳實踐。有四方面的內容：

1、決定緩存的內容

頁面輸出緩存可緩存各種信息，緩存這些信息意味著你不需要經常處理同樣的數據和結果，包括：

·經常被請求但不不改變的靜態頁面；

·更新頻率和時間已知的頁面（如顯示股票價格的頁面）；

·根據HTTP參數，有幾個可能輸出的頁面（如根據城市的代號顯示該城市天氣情況的頁面）；

·從Web Service返回的結果；如：

[WebMethod(CacheDuration=60)]

public string HelloWorld()

{

return "Hello World";

}

2、緩存動態頁面

基于輸入參數、語言和瀏覽器類型改變的動態網頁經常用到。你可以使用OutputCache的以下屬性來實現對動態頁面的緩存：

VaryByParam——基于輸入參數不同緩存同一頁面的多個版本；

VaryByHeader——基于Page Header的內容不同緩存頁面的多個版本；

VaryByCustom——通過聲明屬性和重載GetVaryByCustomString方法來定制緩存處理頁面的多個版本；

VaryByControl——基于控件中asp對象屬性的不同來緩存控件。

對多個版本頁面的緩存會降低可用內存，所以要仔細衡量緩存策略。s

3、控制緩存的位置

你可以使用@OutputCache指令的OutputCacheLocation屬性的枚舉值來指定緩存的位置，如：

%@ outputcache duration="10" varybyparam="none" Location="Server" %>

4、配置頁面輸出緩存

有兩種方式控制，你可以使用Page指令，也可以使用Cache API編程實現。參考以下兩段代碼：

//代碼1，使用指令

%@ OutputCache Duration="20" Location="Server" VaryByParam="state" VaryByCustom="minorversion" VaryByHeader="Accept-Language"%>

//代碼2，編程實現

private void Page_Load(object sender, System.EventArgs e)

{

// Enable page output caching.

Response.Cache.SetCacheability(HttpCacheability.Server);

// Set the Duration parameter to 20 seconds.

Response.Cache.SetExpires(System.DateTime.Now.AddSeconds(20));

// Set the Header parameter.

Response.Cache.VaryByHeaders["Accept-Language"] = true;

// Set the cached parameter to 'state'.

Response.Cache.VaryByParams["state"] = true;

// Set the custom parameter to 'minorversion'.

Response.Cache.SetVaryByCustom("minorversion");

…

}

2.1.2.2 頁面片斷緩存
有時候緩存整個頁面并不靈活，同時內存的發但也比較大，這時候應考慮片斷緩存。頁面片斷緩存適合以下類型的數據：

·創建開銷很大的頁面片斷（控件）；

·包含靜態數據的頁面片斷；

·可被多個用戶使用的頁面片斷；

·多個頁面共享的頁面片斷（如公用菜單條）

以下是緩存部分頁面的例子：

// Partial caching for 120 seconds

[System.Web.UI.PartialCaching(120)]

public class WebUserControl : System.Web.UI.UserControl

{

// Your Web control code

}

2.1.3 在非Web項目中使用Asp.net緩存
Asp.net Cache位于System.Web命名空間，但由于它是一個通用的方案，所以仍然可以在引用此命名空間的任何非Web項目中使用它。

System.Web.Caching.Cache 類是對象的緩存，它可以通過System.Web.HttpRuntime.Cache 的靜態屬性或System.Web.UI.Page 和System.Web.HttpContext.Cache來訪問。因此在請求上下文之外也可以存在，在每個應用程序域中只有一個實例，所以HttpRuntime.Cache對象可以在Aspnet_wp.exe之外的每個應用程序域中存在。以下代碼演示了在普通應用里訪問Cache對象：

HttpRuntime httpRT = new HttpRuntime();

Cache cache = HttpRuntime.Cache;

2.2 使用Remoting Singleton緩存
.Net Remoting提供了跨應用程序域、跨進程、跨計算機的程序運行框架。服務器激活的對象有兩種激活模式，其中Singleton 類型任何時候都不會同時具有多個實例。如果存在實例，所有客戶端請求都由該實例提供服務。如果不存在實例，服務器將創建一個實例，而所有后繼的客戶端請求都將由該實例來提供服務。由于 Singleton 類型具有關聯的默認生存期，即使任何時候都不會有一個以上的可用實例，客戶端也不會總接收到對可遠程處理的類的同一實例的引用。所以將數據緩存起來可以在多個客戶端之間共享狀態信息。

為了使用.Net Remoting實現緩存方案，要保證遠程對象的租約不過期，并且遠程對象沒有被垃圾回收器銷毀（對象租約是指在系統刪除該對象前它在內存中的生存期）。當實現緩存時，重載MarshalByRefObject的InitializeLifetimeService方法并且返回null，這樣就能保證租約永遠不過期并且相關的對象生存期是無限的。以下代碼是一個示例：

public class DatasetStore : MarshalByRefObject

{

// A hash table-based data store

private Hashtable htStore = new Hashtable();

//Returns a null lifetime manager so that GC won't collect the object

public override object InitializeLifetimeService() { return null; }

// Your custom cache interface

}

注意：由于這種方案的成本較高、性能上的限制并且可能造成系統不穩定，通常采用基于Sql Server的方案來替代。

2.3 使用內存映射文件（Memory-Mapped File）
內存映射文件提供獨一無二的特性，允許應用程序通過指針來訪問磁盤上的文件——與訪問動態內存趣的方式一樣。所以你可以將應用程序進程中的某個地址段的數據映射到文件中，供多個跨應用程序域或跨進程訪問。

在windows中，代碼和數據是以以種方式處理的，表現形式都是內存頁，而在內存頁背后都是磁盤上的文件。唯一的不同磁盤上的文件類型不同。代碼后面是可執行的鏡像，而數據后面則是系統的頁面文件。當多個應用程序共享內存時，系統的性能會有明顯提升。

你可以使用內存映射文件的這種特性來實現同一臺機器上的跨進程和跨應用程序域的緩存解決方案。基于內存映射文件的緩存方案包含以下組件：

·windows NT服務——啟動時創建內存映射文件，停止時刪除它。功能是向使用緩存的進程提供句柄。當然，也可以使用命名的內存映射文件來提供操作接口；

·緩存托管組件（Cache Management Dll）——實現特定的緩存功能，比如：

a. 插入和刪除數據項到緩存中；

b. 使用算法清除緩存，比如最后使用算法（Least Recently Used）；

c. 保證數據不被篡改；

基于內存映射文件的緩存方案可以用在應用程序的每個層中，但由于使用win32 API調用，所以并不容易實現。.Net 框架不支持內存映射文件，所以只能以非托管代碼的方式運行，當然也不能利用.Net框架的有力特性，比如垃圾回收等。同時緩存數據項的管理功能需要定制開發，還要開發性能計數器來監控緩存的效果。

2.4使用SQL Server緩存
如果需要在進程回收（重啟）、機器重啟或電源故障的過程中保持緩存數據的有效，基于內存的方案并不能滿足要求。你可以使用基于永久數據存儲的方案，如SQL server數據庫或NTFS文件系統。

SQL Server在使用sql語句或存儲過程得到數據時，對varchar和varBinary類型的數據有8k的大小限制，你必須使用.Net 框架提供的Ado.Net SQLDataAdapter對象來訪問datatable或dataset。

使用SQL Server緩存數據的優點：

·易于實現——使用.Net 框架和Ado.Net訪問數據庫相當方便；

·完善的安全模型和很高的健壯性；

·數據非常方便的共享；

·數據的持久保留。

·支持很大的數據量。

·方便的管理工具

當然，也有缺點：

·需要安裝SQL Server，對小型應用來說不合適；

·重新構造數據的性能和讀取數據庫的性能比較；

·網絡負擔。

2.5 使用靜態變量緩存
靜態變量常用來記錄類的狀態，你可以用它來創建定制的緩存對象。在定制的緩存類中將你的數據存儲器聲明為靜態變量，并且提供維護接口（插入、刪除和訪問等）。如果沒有特殊的緩存需求（比如依賴、失效策略等），使用靜態變量緩存數據是很方便的。由于是在內存中，這種方案可提供對緩存數據的直接、高速的訪問，當沒有替代方案解決鍵值對的存儲且對速度要求很高時，可以使用靜態變量。當然，在asp.net中，應該使用Cache對象。

你可以使用這種方案保存大數據的對象，前提是它不經常更改。由于沒有清除機制，大數據的內存消耗會影響性能。

你需要保證定制線程安全機制，或者使用.Net框架提供的同步對象，比如Hashtable。以下代碼是使用Hashtable實現的例子：

static Hashtable mCacheData = new Hashtable();

應用范圍：本方案的應用范圍可以限制到類、模塊或整個項目。如果變量定義為public，整個項目中的代碼都能訪問它，范圍是整個應用程序域，實現了高效的共享。而它的生存期是和范圍緊密相關的。

2.6 使用asp.net session state
你可以使用基于HttpSessionState對象的asp.net session state來緩存單個用戶的會話狀態信息。它解決了asp中會話狀態的很多限制，包括：

·asp session要求客戶端接受cookies，否則就不能使用session；而asp.net可以配置為不使用cookie；

·對web server場的情況，asp的session不能支持；當穩定性和可用性要求很高時，asp.net session state雖然效果不好，但對比較小的單個值scalar Value（比如登錄信息），還是很有效。

Asp.net session有很大改進，下面描述使用范圍和使用方式。

Asp.net session state有三種操作模式：

1、進程內模式InProc——Session State信息在asp.net工作進程aspnet_wp.exe的進程的內存中存儲。這是默認選項，這種情況下，如果進程或應用程序域被回收，則Session 狀態信息也被回收；

2、進程外模式State Server——狀態信息序列化后保存在獨立的狀態進程中（AspNet_State.exe），所以狀態信息可以保存在專門的服務器上（一個狀態服務器State Server）；

3、 Sql server模式——狀態信息序列化后保存在SQL Server數據庫中。

你可以通過調整配置文件中sessionState>標簽的mode屬性來設置要使用的狀態模式，比如使用SQL Server模式來在Web server場中共享狀態信息。當然，這個優勢也有缺點，就是狀態信息需要序列化和反序列化，同時多了對數據庫的寫入和讀取，所以性能上有開銷，這是要仔細評估的。

2.6.1 選擇使用模式
2.6.1.1 使用InProc模式
當使用進程內模式時，狀態信息保存在aspnet_wp.exe的進程中。由于在web場的情況下aspnet_wp.exe的多個實例在同一臺服務器上運行，所以進程內模式不適用與web場的情況。

進程內模式是唯一支持Session_End事件的session模式，當用戶會話超時或中止時，可以運行Session_End中的事件處理代碼來清除資源。

2.6.1.2 使用StateServer模式
StateServer模式使用指定的進程儲存狀態信息。因為它也是一種進程外模式，所以要保證你存儲的對象是可序列化的，以支持跨進程傳輸。

當使用Session對象在web場的情況下使用時，必須保證web.config文件中的MachineKey>元素在所有服務器上是唯一的。這樣所有的服務器使用同樣的加密方式，才能訪問緩存中的數據。參考msdn中的“MachineKey元素”。

2.6.1.3 使用SQL Server模式
SQL Server模式下，當你使用信任連接（trusted_connection=true 或 integrated security=sspi）訪問Session state信息時，不能在asp.net中使用身份用戶模擬。

默認情況下，SQL Server將狀態信息存儲在TempDb數據庫中，它在每次Sql server服務啟動時會自動重新創建，當然，你可以指定自己的數據庫以便在數據庫重啟的過程中也能保持數據。

2.6.2 決定使用Session對象要存儲的內容
你可以使用Session對象緩存任何類型的.net框架數據，但是要了解對某種類型來說最好的方式是什么。有以下幾點需要說明：

1、對基本類型（比如Int,Byte,String）來說，可以使用任何方式。因為在選用進程外方式時，asp.net使用一個優化的內部方法來序列化和反序列化基本類型的數據；

2、對復雜類型（如ArrayList）來說，只選用進程內方式。因為asp.net使用BinaryFormatter來序列化和反序列化這類數據，而這會影響性能的。當然，只有在State Server和SQL Server的方式下，才會進行序列化操作；

3、緩存的安全問題，當在緩存中存儲敏感數據時，需要考慮安全性，其它頁面可以訪問到緩存中的數據；

4、避免緩存大數據，那會降低性能；

5、這種緩存方式不支持過期策略、清除和依賴。

2.6.3 實現Session State
Asp.net提供了簡單接口來操作Session State，并可使用Web.Config進行簡單設置，當配置文件中的設置改變時，能夠在頁面上立刻體現出來，而不需要重新啟動asp.net進程。

以下代碼演示了使用SQL Server來實現Session數據的存儲和使用。

sessionState

mode="SQLServer"

stateConnectionString="tcpip=127.0.0.1:42424"

sqlConnectionString="data source=127.0.0.1; Integrated Security=SSPI"

cookieless="false"

timeout="20"

/>

private void SaveSession(string CartID)

{

Session["ShoppingCartID"] = CartID;

}

private void CheckOut()

{

string CartID = (string)Session["ShoppingCartID"];

if(CartID != null)

{

// Transfer execution to payment page.

Server.Transfer("Payment.aspx");

}

else

{

// Display error message.

}

}

2.7使用Asp.net客戶端緩存和狀態
你還可以使用客戶端存儲頁面信息的方式來降低服務器的負擔，這種方法提供最低的安全保障，但卻有最快的性能表現。由于需要將數據發送到客戶端存儲，所以數據量有限。

實現客戶端緩存的機制有以下五種，接下來將依次介紹：

·隱藏欄位（Hidden Field）

·View State

·隱藏幀（Hidden Frame）

·Cookies

·Query String

這五種方式分別適合于存儲不同類型的數據。

2.7.1 使用Hidden Field
你可以將經常改變的少量數據保存在HtmlInputHidden中來維護頁面的狀態。當每次頁面回送的過程中，這些數據都會包含在表單中大送到服務器，所以你要使用HTTP POST方式來提交頁面。

使用這種方式的優點如下：

不需要服務器資源，直接從頁面中讀取；
幾乎所有的瀏覽器都支持；
實現簡單；
由于數據在頁面中，所以在web Farm的情況下也可使用。
缺點：

由于可以通過查看源碼看到，所以可能會被篡改；
不支持復雜格式的數據，復雜數據必須使用解析字符串的方式來間接得到；
當存儲大數據的時候會影響性能。
示例：

input id="HiddenValue" type="hidden" value="Initial Value" runat="server" NAME="HiddenValue">

2.7.2 使用View State
所有的Web Form頁面和控件都包含有一個ViewState屬性，在對同一頁面多次請求時可以保持頁面內的值。它的內部實現是維護相應的hidden field，只不過是加密了的，所以比hidden field的安全性要好。

使用View State的性能表現很大程度上依賴于服務器控件的類型。一般來說，Label,TextBox,CheckBox,RadioButton,HyperLink的性能要好一些，而DropdownList,ListBox,DataGrid和DataList就要差很多，因為包含的數據量太大，所以每次頁面回送都很耗時間。

有些情況下不推薦使用ViewState，比如：

1、不需要回送的頁面避免使用；

2、避免使用ViewState保存大數據量；

3、在需要使用會話超時的情況下避免使用它，因為它沒有超時操作。

ViewState的性能表現和Hidden Field的是類似的，但是具有更高的安全性。

優點：

數據在頁面中自動維護，不需要服務器資源；
實現簡單；
數據是經過加密和壓縮的，比hidden field有更高的安全性；
數據存在客戶端，可以在Web Farm情況下使用。

缺點：

存儲大數據量時會降低性能；
和hidden field類似，在客戶端數據仍然有潛在的安全威脅。
示例代碼如下：

public class ViewStateSample : System.Web.UI.Page

{

private void Page_Load(object sender, System.EventArgs e)

{

if (!Page.IsPostBack)

{

// Save some data in the ViewState property.

this.ViewState["EnterTime"] = DateTime.Now.ToString();

this.ViewState["UserName"] = "John Smith";

this.ViewState["Country"] = "USA";

}

}

…

private void btnRefresh_Click(object sender, System.EventArgs e)

{

// Get the saved data in the view state and display it.

this.lblTime.Text = this.ViewState["EnterTime"].ToString();

this.lblUserName.Text = this.ViewState["UserName"].ToString();

this.lblCountry.Text = this.ViewState["Country"].ToString();

}

}

2.7.3 使用Hidden Frame
你可以使用Hidden Frame在客戶端緩存數據，這就避免了使用hidden field和使用view state時每次頁面回送時的緩存數據往返。比如你可以秘密的加載多個頁面所需要的圖片，這并不會消耗服務器資源。

優點：

a. 可以加載較多數據而不只是單個欄位的值；

b. 避免了不必要的多次回送中的數據往來；

c.可以緩存和讀取在不同表單中存儲的數據項（可以同時緩存多個頁面的數據）；

d.可以訪問同一站點不同frame中的客戶端腳本數據。

缺點：

a. 有些瀏覽器不支持frame；

b. 源代碼可以在客戶端看到，有潛在的安全威脅；

c. 隱藏frame的數量沒有限制，如果框架頁面包含較多hidden frame的話，在首次加載時速度會有限制。

示例代碼如下：

FRAMESET cols="100%,*">

FRAMESET rows="100%,*">

FRAME src="contents_of_frame1.html">

/FRAMESET>

FRAME src="contents_of_hidden_frame.html">

FRAME src="contents_of_hidden_frame.html" frameborder="0" noresize scrolling="yes">

NOFRAMES>

P>This frameset document contains:

A href="contents_of_frame1.html" TARGET="_top">Some neat contents/A>

/NOFRAMES>

/FRAMESET>

2.7.4 使用Cookies
Cookie是可以在客戶端存儲數據另一種方案，這里不過多介紹。

優點：

不需要服務器資源；數據保存在客戶端，在用戶請求時發送到服務器上。
使用簡單。Cookie包含簡單的鍵值對，主要保存輕量級的文本數據。
支持過期策略；可以指定當會話結束時過期，也可指定一個時間策略。

缺點：

數據量的限制；
用戶可能設置為拒絕Cookie；
安全問題；用戶可能更改機器上的cookie信息，造成基于cookie的系統運行失敗；
可能過期或被用戶刪除，造成一定程度的不可用。
參看示例代碼：

public class CookiesSample : System.Web.UI.Page

{

private void Page_Load(object sender, System.EventArgs e)

{

if (this.Request.Cookies["preferences1"] == null)

{

HttpCookie cookie = new HttpCookie("preferences1");

cookie.Values.Add("ForeColor","black");

cookie.Values.Add("BackColor","beige");

cookie.Values.Add("FontSize","8pt");

cookie.Values.Add("FontName","Verdana");

this.Response.AppendCookie(cookie);

}

}

private string getStyle(string key)

{

string val = null;

HttpCookie cookie= this.Request.Cookies["preferences1"];

if (cookie != null)

{

val = cookie.Values[key];

}

return val;

}

}

2.7.5 使用Query String
Query String是在用戶請求的URL后加上相應的參數來使用的，只能在使用HTTP GET方式調用URL時可用。

優點：

d.不需要服務器資源，參數附在URL里面；

e. 應用面廣，幾乎所有瀏覽器都支持；

f.實現簡單，服務端使用Request對象可直接讀取。

缺點：

a.參數直接對用戶可見，不安全；

b.URL長度的限制，多數瀏覽器不支持超過255字符的URL。

示例代碼：

string user = Request.QueryString["User"];

2.7.6 小結
下表是使用客戶端緩存的建議：