如何讓使用SQL Server In-Memory存儲ASP.NET的會話狀態

如何讓使用SQL Server In-Memory存儲ASP.NET的會話狀態，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

從以前的 “classic” ASP 到目前的 ASP.NET 4.5 Web Forms，很多開發者依賴ASP.NET 會話狀態作為重要的臨時保存每個用戶的數據的主要手段。 它的特征是在用戶訪問web應用程序的過程中，允許開發者存儲和讀取用戶的數據。 會話數據是自動從存儲中持續保存和恢復,并且自動過期刪除。

問題

使用Session State的替代方案這些內容超出了本文的范圍。 對于依賴Session State的應用程序也有陷阱，最常見的是訪問每個用戶，每個請求的Session基礎數據。這種獨特的訪問是維持Session State的一致性的一種方式，并且是通過設計實現了這種方式。 如果你對這樣殘暴細節的設計感興趣， 他們在題名為“鎖定會話狀態數據”章節這里解釋了。會話狀態常見于ASP.NET Web窗體應用程序，而ASP.NET MVC在較小程度上使用了TempData（POST數據到GET作為例子） 。

Web應用程序主要利用Session狀態來協調彼此間的工作。作為對比，客戶端腳本較多的重量級web應用通常擁有更高的并發請求，這種情況下使用Session狀態訪問資源需要對Session加鎖和解鎖，從而成為了Web應用的瓶頸。不限制類型的Web應用將會成為另外一個瓶頸因為需要足夠的存儲空間維持它們的會話的狀態。有三種途徑優化Session狀態的訪問，使得一些請求可以不需要session或者使用只讀的，但是如果加載后應用規模持續增大，最終仍然會有瓶頸。

目前的狀況

基于這些考慮目前的ASP.NET的會話狀態仍然使用的非常普遍。在許多領域我不斷看到許多消費者在有大量擴展的Web應用中使用會話狀態。對大量企業級用戶而言，內部使用ASP.NET窗體應用更為普遍。對于這些消費者而言，如何選擇Session State存儲提供商是相當關鍵的。這些提供商必須將Session字典的內容序列化存儲在耐用的設備上并反序列化從中提取數據（通常使用BLOB應用程序）。這里有許多提供商可供選擇，包括Microsoft和第三方開發者提供的工具。目前Microsoft提供了下面的Session存儲工具，假定ASP.NET應用部署在企業內部：

*需要在 in-memory表中將模式和數據標記為持久的

如果你的應用程序需要Session State高可用,同時支持跨web farm的部署,你可以從Microsoft提供的選項,僅限于SQL Server或者AppFabric Caching.SQL Server有一個增加的優勢,它可以跨越數據中心來提供地理冗余(geo-redundancy).而AppFabric則受限于單一數據中心.實際應用中,這兩種解決方案都工作良好.但是,傳統的SQL Server實現常常遇到瓶頸,產生的原因是基于單一磁盤的表存在競爭.競爭導致阻塞,死鎖,或者其它不友好的變化.這影響了它存儲和恢復會話的時間.另外,在刪除操作過程中,當先前的會話數據由于鎖的擴大和競爭的延續而清除了,這也會存在問題.

SQL Server 2014的新選項

為了解決老版本SQL Server安裝包的性能問題,SQL Server團隊最近發布了新的安裝包“Microsoft ASP.NET Session State provider for SQL Sever In-Memory”作為NugGet包.在this case study中有這個安裝包不可思議的性能提升的證明.它在ASP.NET應用程序中使用Session State,每秒處理250,000個請求!這個新實現使用了SQL Server 2014稱為"Hekaton"的內存優化表特性.這需要這個產品的2014版本.這個安裝包如何在老版本SQL Server會話狀態安裝包上有所提升的呢?

1. 會話存儲的持續性是通過內存優化表而不是磁盤表.對于繁重的訪問模型,如存儲會話狀態等,內存優化表是全事務的,可持續性和理想的.這類表使用無鎖數據結構和優化的,多版本的并發控制.

2. 為了更進一步提升性能,可用本地編譯存儲過程來恢復和存儲會話數據. 本質上,這是一種新型的存儲過程,它被編譯為本地機器代碼.

這兩個SQL 2014產品特性,解決了主要的性能和競爭問題,這些問題存在于基于磁盤實現的舊的傳統的SQL Server安裝包.安裝和配置這個程序是相當直接的.通過NuGet包管理控制臺,可以按照下面的方式安裝:  
   
Install-Package Microsoft.Web.SessionState.SqlInMemory. 

在你的應用程序中,NuGet包將增加一個到Microsoft.Web.SessionState.SqlInMemory的引用,同時也會增加一個名為ASPStateInMemory.sql的腳本文件來安裝SQL Server 2014 Session State數據庫.這個文件包含了必須的DDL來安裝數據庫.在SQL腳本中有一些項,你想要審查或者最可能審查或修改的:

1. 這個數據庫的名字默認是ASPStateInMemory.

2. 數據庫的主文件組路徑.

3. 數據庫的MEMORY_OPTIMIZED_DATA文件組路徑.

4. BUCKET_COUNT的大小信息,它基于會話中的項的預期大小.

5. 讓會話中的表可持久或非可持久的決定(涉及到是否需要會話高可用)

以上的第五個部分,需要對已經存在的SQL Server會話數據庫作一些分析,它可能像計算傳統ASP.NET SQL Server會話模式里BLOB列的DATALENGTH()一樣簡單.對于InProc或者StateServer來說,決定會話項的平均大小會更加困難,但可以通過捕獲w3wp.exe或者StateServer進程的內存dump來實現,其間檢查在會話字典中的項的數目和大小.對于InProc或者StateServer,關于會話中的項的數目,有性能計數.***的建議總是測試和調整.

讓基于內存的會話高可用

默認,SQL Server 2014基于內存會話的內存優化表是標記為非持久的.這意味著,這些表里的數據變化是過渡性的一致.這些變化沒有記錄在日志中,這意味著如果SQL Server重啟了,服務器重啟了或者任何形式的故障恢復發生(FCI或者AlwaysOn),所有的會話數據將丟失.設置這個默認值是因為性能.為了讓這些內存優化表可持續,需要在ASPStateInMemory.sql腳本中做三點改變.在腳本中有一些注釋解釋了為何需要做這些改變.

1. 按下面的方式修改SessionItems表.

1. 修改WITH (MEMORY_OPTIMIZED=ON, DURABILITY=SCHEMA_ONLY)

2. 為WITH (MEMORY_OPTIMIZED=ON, DURABILITY=SCHEMA_AND_DATA)

3. 取消語句的注釋(注意***的逗號): Id bigint IDENTITY,

4. 取消語句的注釋(注意***的逗號,根據需要修改1000000 * 2為real值,在這個語句前讀T-SQL注釋以選擇一個起始值): CONSTRAINT [PK_SessionItems_Id] PRIMARY KEY NONCLUSTERED HASH (Id) WITH (BUCKET_COUNT = 2000000),        

2. 修改會話表

1. 修改WITH (MEMORY_OPTIMIZED=ON, DURABILITY=SCHEMA_ONLY

2. 為WITH (MEMORY_OPTIMIZED=ON, DURABILITY=SCHEMA_AND_DATA)

只要做了這些修改,我們可以讓數據庫成為部分SQL Server AlwaysOn可用性組.當故障恢復時,會話數據將會保留.由于增加的重試邏輯,所以,當一個自動的或者人為的故障恢復發生時,連接池中的過期連接不會產生異常拋出給終端用戶.

請注意,即使我們設置表為非可持續的,將會話數據庫放入SQL Server AlwaysOn可用性組,但會話表中的數據在復制(只有schema可用)時不可用.對于客戶負荷,這個"schema only"復制模型,通過使用非可持續內存優化表,已足夠來保證性能提升.

這個最簡單的高可用的拓撲對SQL Server In-Memory來說是最合適的,它與下面的類似:

1. 位于子網(數據中心)A的SQL Server 2014 Node 1

2. 位于子網(數據中心)B的SQL Server 2014 Node 2

3. 位于子網(數據中心)C的文件共享

這個拓撲提供了地理冗余,自動故障恢復和維持了1/3的數據中心完整的丟失連接.Windows Server 2012 R2的動態特性,使得自動維持2個數據中心的丟失連接成為可能.(***的男人的場景[last man standing scenario]).

ASP.NET 配置文件

在 ASP.NET web 應用程序的配置文件web.config中，配置一個新的provider，并且按照下面編輯它。

<sessionState mode="Custom" customProvider="SqlInMemoryProvider">  
  <providers>    
    <add name="SqlInMemoryProvider"    
         type="Microsoft.Web.SessionState.SqlInMemoryProvider"    
         connectionString="Data Source=AGAspNet; Initial Catalog=ASPStateInMemory;Integrated Security=True;" />    
  </providers>    
</sessionState>

在上面的代碼片段中， &lsquo;AGAspNet&rsquo;  是SQL Server 2014 中永遠可用的監聽者名字。

一個快速的例子

使用ASP.NET網頁表單4.5應用,并在會話中編寫簡單的帶有時間戳的字符串,SQL Server 2014中便生成如下的數據:

注意在SQLNode1-2014中,AspStateInMemory數據庫的位置.接下來,我們手動進行故障恢復可用性組.

在SQLNode2-2014上,會話現在可用了,而且不會干擾ASP.NET應用程序.簡單的敲擊web應用程序的F5,以獲取來自會話的數據,而不會向客戶端拋出異常.

過期會話會怎么樣呢?
 

在舊的SQL Server會話中,一個SQL Agent作業創建后用來刪除過期會話.在新版本中,提供了一個必須被作業調用的存儲過程[dbo].[DeleteExpiredSessions].默認,會話超時時間為20分鐘.每次一個會話項被訪問,超時被重置以保持用戶會話“存活”.

概述

在新的會話狀態中,有許多有意思的細節.我鼓勵你為自己而深入研究代碼.你將會發現它是一段奇妙的學習旅程,其間是關于SQL Server 2014 基于內存的OLTP "Hekaton"特性的性能和限制.一個特別的屬性包含在代碼中,以模擬內存中存儲BLOB類型的數據.內存優化表現在不支持BLOB類型.序列化的會話字典和可能的大BLOB數據類型有什么不同呢?其中使用的預處理程序(sprocs)將序列化的會話分拆為7000字節的數據塊,以增強大的會話項數據的存儲.

精明的讀者可能已經發現,在我的屏幕截圖中, [SessionItems]表中并沒有數據行,但在[Sessions]表中有一行數據.如果我的會話內容超過了7000字節,你應該會在[SessionItems]表中看到"溢出"(spill over)行.關于這方面,在ASP.NET會話存儲之外,有許多其它潛在的應用程序,我很可能在下一篇文章中深入挖掘這點.

本地編譯存儲過程也值得一看.有一些技巧來處理本地編譯存儲過程的限制,如缺少CASE語句的支持.這個限制是因為,只要預處理程序(sproc)編譯為本地代碼,是不允許進行分支的!

如果你在考慮使用這個新特性,有如下關鍵點和問題需要考慮:

1. 內存優化表由內存來支撐!你的SQL Server在峰值負載時,有足夠的內存來包含所有的會話數據嗎?

2. 默認表是非可持久的.請仔細考慮你的高可用性的需求.不管是可持久還是非可持久,性能將超出你現在使用的傳統SQL Server數據庫的會話和模式.

3. 閱讀SQL文件中的注釋,調整BUCKET_COUNT為非簇集HASH索引.以下是SessionItems表DDL語句的代碼片段.    
        
   

關于如何讓使用SQL Server In-Memory存儲ASP.NET的會話狀態問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。