ASP.NET應用下基于SessionState的“狀態編程框架”解決方案

作者: Artech 來源: 博客園發布時間: 2010-11-02 14:20 閱讀: 764 次推薦: 0 原文鏈接 [收藏]

　　在一個基于ASP.NET的Web應用程序中，我們通常使用SessionState保存基于某個客戶端的狀態信息。但是這種單純使用SessionState的編程方式具有很多局限，比如Session Item的Key值沖突，比如沒有一個有效的SessionState清除機制會為Web Server帶來內存壓力。為了實現對客戶端狀態的有效管理，并提高應用開發效率，在很多年前我們的開發框架體系中就具有相應的一個叫做State的編程框架。最近我開始對其進行升級和重新設計，將實現原理和概要設計方面的東西寫出來與大家共享，希望對各位有些啟發。同時希望借此得到你們一些好的建議和意見，以便能夠充實我們的框架。于此同時，我寫了一個簡單的模擬程序實現了該設計思想，有興趣的話可以通過這里下載該模擬程序。

　　一、單純基于SessionState編程的局限性

　　SessionState對于ASP.NET的開發者在熟悉不過了，我們可以通過它來存儲一些基于客戶端的狀態信息。從編程角度來說，SesssionState是依附和當前HttpContext的一個用于類似于字典的數據容器，我們通過鍵值對的方式進行Session Item的設置和獲取。但是這種單純地基于字典索引的編程方式，具有諸多局限：

首先，這種弱類型的編程方式不便于快速開發需求。放入SessionState的值是一個System.Object類型的對象，在獲取的使用我們需要進行手工轉型；而Session Item的Key是手工指定的字符串，如果沒有對Key值進行有效的分配，在進行設置的時候很容易造成一個Key值得沖突，從而導致整個狀態的混亂；在獲取某個Session Item的時候，你指定的Key值可能和預先指定的不符。
其次，統一的SessionState的清除機制的缺乏導致服務端內存壓力。在默認的情況下（采用InProc會話模式），SessionState存儲于服務端內存，如果過多、過大的Session Item常駐內存，勢必會為服務端帶來內存壓力。實際上，基于客戶端的所有的Session Item并不是在整個Session存續期間都是必須的，很多Session Item僅僅是在某幾個少數的Web頁面中使用。但是我們不能通過程序手工地將其從SessionState中刪除，因為我們不能確定該Session Item在那一刻不再需要，因為這往往取決于UI交互的行為。如果太多的低頻率使用的Session Item存在，并且它們還不小，服務端內存過多地被占用必要導致性能的下降。
最后，如果你采用State Server或者SQL Server會話管理模式，還會造成更多的性能問題。這樣的性能損失包括：Session Item的序列化和反序列化、序列化后的Session Item在Web Server和State Server或者SQL Server的網絡傳輸、針對State Server或者SQL Server的數據存取（保存和提取）等。

　　實際上，我們的State框架還是建立在SessionState基礎之上，但是它能夠很好的解決上述的三大難題：

通過配置為所有使用到的狀態項（狀態屬性名稱、數據類型等）提供結構化的定義，并通過基于該結構化配置提供的代碼生成使強類型編程成為可能。這比較類似于ASP.NET中Profile的配置和強類型編程的方式；
提供狀態的后備存儲（Backing Storing）機制將低頻率使用的大對象從SessionState中移到相應的后備存儲（比如文件、數據庫）中，從而緩解服務端內存壓力；
提供靈活的后備策略定義方式以實現基于具體運行環境的最優配置。后備策略主要包括兩方面的內容，其一是怎樣的狀態項需要被后備存儲，其二采用怎樣的方式進行后備存儲。確定后備存儲狀態項的因素包括：自最近一次被訪問以來的超時時限（通過使用頻率判斷狀態項再次被使用的可能性）；需要被后備存儲對象必須具有的最小字節數（后備存儲小對象毫無意義）；以及狀態項的作用域（很多狀態項的作用范圍僅僅限于某一個相關的Web頁面，或者基于某個基地址）等。而具體采用的后備存儲方式決定于配置的“后備存儲器”，比如在我提供的例子中采用的是基于文件的存儲方式，你可以編寫基于數據庫的后備存儲器。

　　二、通過狀態后備存儲機制解決Web Server內存的壓力

　　狀態的后備機制是整個狀態編程框架的核心。通過對所有狀態項的掃描，標記出所有需要進行后備存儲的狀態項。然后將它們進行序列化，并借助于指定的后備存儲器將它們存儲到相應的物理存儲介質。最后，相應的狀態會從SessionState中刪除，從而緩解了Web Server的內存壓力。除了將序列化的狀態對象進行后備存儲之前，后備存儲器還負責從相應的存儲介質中提取狀態數據。

　　簡單起見，我們并沒有在后臺運行一個實施后備檢測操作的引擎，而是直接通過事件注冊的方式讓每一個請求自動去觸發基于本會話的后備存儲，我們注冊的事件是HttpApplication的PostRequestHandlerExecute。出于性能的考慮，當事件PostRequestHandlerExecute被觸發的時候，并不是總是立即執行后備狀態項的檢查。而是設置一個相鄰兩次后備檢查的間隔，只有超出這個間隔的情況下，才會進行真正地區檢查那些狀態向需要進行后備存儲了。狀態項的后備存儲緊接著在后備對象的檢查之后進行。

　　我們通過一個具體的例子來進一步說明后備存儲的過程。如左圖（點擊看大圖）所示，在Web Server的IIS進程中的SessionState中維持著三個狀態項：Foo、Bar、Baz。當Web Server接收并執行來自瀏覽器的HTTP請求后，PostRequestHandlerExecute事件的處罰激活了我們的后備檢查管理器，它發現狀態項Baz最近一次被訪問的時間到當前時間的間隔已經超出了設置的超時時限，并且計算出該對象的總字節數超過了設定的下限，就會將該對象標記為后備存儲對象。在這種情況下，狀態項Baz的值，同它的Key一并進行序列化并進行后備存儲。最后將該Baz從SessionState中移除。

　　如果該Web應用使用Web Farm部署方式，并采用了Sate Server或者SQL Server的會話模式，在同步到Sate Server或者SQL Server的時候，由于SessionState中缺少了Baz這個大對象，也會因為少了對它序列化、網絡傳輸和數據存取使性能得到相應的提升。

　　三、后備存儲狀態項的“復蘇”

　　被后備存儲的狀態項已經不再存儲于SessionState中，但是并不意味著它已經是所謂的垃圾對象，它們依然可以被再次訪問。在這種情況下，我們會通過我們指定的后備存儲器將相應的狀態值以字節數組的形式從存儲介質中提取出來，進行反序列化后再次放到SessionState中，我個人將這種機制成為“后備對象的復蘇”。

　　在對后備對象的復蘇機制進行進一步講解之前，我們需要了解一個前提：框架始終維護著每一個狀態項運行時信息，這些信息包括：狀態項最后一次被訪問的時間、狀態項的使用范圍、狀態項當前的存儲位置（SessionState或者BackingStore）、以及相關的后備策略信息等。這個列表放在SessionState中。

　　右面所示的序列圖（點擊看大圖）反映了當我們的程序獲取某個狀態項時，狀態后備機制采用的處理流程：當接收到一個來自對某個狀態項的請求時，根據Key值獲取該狀態項當前的運行時信息。如果運行時信息反映它還存在于SessionState中（Location=Session），則直接從SessionState中返回，并更新它的運行時信息（最后一次被訪問時間）。

　　如果該狀態項已經進行了背后存儲（Location=BackingStore），則借助相應的后備存儲器從存儲介質中對應的值以字節數組的形式提取出來。在完成反系列化后再次保存到SessionState中，并更新相應運行時信息（最后一次訪問時間和當前位置：BackingStore-〉Session）。最后返回反序列化后的具體狀態對象。

　　四、狀態項后備策略的定義

　　判斷一個存在于SessionState中的狀態項是否應該被后備存儲取決于以下三個方面，當同時滿足條件1和2，或者2和3的狀態項會被后備存儲。

針對該狀態項的最近一次訪問的事件到當前時間的間隔超過了設定的超時時限；
狀態項的總的字節數超過了設定的需要進行后備存儲的下限；
當前的請求的URL是否超出了設定的狀態作用的范圍。

　　但是我們的狀態后備策略并沒有直接應用于單個的狀態項，而是應用于一個較大的粒度：狀態組——若干相關狀態項的組合。狀態組的結構和應用在它上面的后備策略通過配置進行定義，下面的XML體現的配置大體上的結構。

<?xml version="1.0" encoding="utf-8" ?>

<states>

  <properties>

    <property name="UserName" type="System.String"/>

    <property name="Position" type="System.String"/>

  </properties>

  <group name="Profile" inactiveTimeout="00:10:00" minimunTotalBytes="1024" >

    <property name="Age" type="System.Int32"/>

    <property name="Address" type="System.String"/>

  </group>

  <group name="Product" inactiveTimeout="00:10:00" minimunTotalBytes="1024" scope="Page1, Page2,Page3" >

    <property name="ProductId" type="System.String"/>

    <property name="UnitPrice" type="System.Decimal"/>

  </group>

</states>

　　在上面的XML片段中，我們定義兩個全局的狀態項（UserName和Position）和兩個狀態組（Profile和Product）。兩個狀態組中又包含各自的狀態項，以及對應的后備策略。inactiveTimeout、minimumTotlaBytes和scope分別表示超時時限、序列化后的最下值和使用的范圍。

　　五、通過代碼生成機制幫助你以強類型的方式操作狀態

　　既然所有的狀態和數據類型（即可以是系統預定義類型，也可以是自定義類型）都能通過XML的形式表示出來，那么我們就能通過代碼生成機制將它們通過代碼的形式反映出來。你可以采用CodeDOM+Cutom Tool的方式[可以參考我的文章《從數據到代碼》（上篇、下篇）]，或者是直接使用T4模板[可以參考我的文章《創建代碼生成器可以很簡單：如何通過T4模板生成代碼？》（上篇、下篇）]。比如說，你可以生成一個繼承自Page的類型，比如PageBase，添加如下一個State的屬性。（下面的代碼僅僅代碼大體的結構，并省略的具體的實現）

public class PageBase : Page
{
public ExtendedRootStateNode State { get; }
}
public class ExtendedRootStateNode : RootStateNode
{
public string UserName { get; set; }
public string Position { get; set; }
public ProfileGroupStateNode Profile { get; private set; }
public ProductGroupStateNode Product { get; private set; }
}
public class ProfileGroupStateNode : GroupStateNode
{
public int Age { get; set; }
public Gender Gender { get; set; }
public string Address { get; set; }
}
public class ProductGroupStateNode : GroupStateNode
{
public string ProductId { get; set; }
public string ProductName { get; set; }
}

　　如果讓你的所有Web頁面都繼承自這個PageBase，你可以通過強類型的方式獲取或者設置每個狀態項了。