ASP.NET通過分布式Session提升性能

如果我們正在使用Session，那么構建高性能可擴展的ASP.NET網(wǎng)站，就必須解決分布式Session的架構，因為單服務器的 SESSION處理能力會很快出現(xiàn)性能瓶頸，這類問題也被稱之為Session同步。微軟有自己的分布式Session的解決方案，那就是 SessionStateServer，我們可以參考：

ASP.NET Session State Partitioning 
http://blog.maartenballiauw.be/post/2008/01/23/ASPNET-Session-State-Partitioning.aspx 

ASP.NET load balancing and ASP.NET state server 
http://blog.maartenballiauw.be/post/2007/11/ASPNET-load-balancing-and-ASPNET-state-server-(aspnet_state).aspx 

不過本文是要換一個方案，那就是使用Memcached來到達分布式SESSION的架構。Memcached作為分布式的緩存服務器已經被廣泛應用在網(wǎng)站建設中。

一：Session的機制

Session是針對用戶的，我們也可以理解為是針對瀏覽器的。在瀏覽器首次訪問ASP.NET網(wǎng)頁的時候（網(wǎng)頁沒有關閉session功能），它會發(fā)送如下的HTTP頭給客戶端：

瀏覽器在收到上面的HTTP頭后，會將這個唯一的SESSIONID保存在自己的COOKIE中（只要沒有禁用COOKIE，本文不討論禁用COOKIE的案例，可參考本博文http://www.cnblogs.com/fish-li/archive/2011/07/31/2123191.html，寫的很NICE）。當瀏覽器再次請求服務器進行訪問的時候，它會在請求HTTP頭中加入如下的標識，我們可以看到，這個SESSIONID就是上面的SESSIONID：

瀏覽器和服務器間就是通過這樣一種機制來確保用戶SESSION的。

如果客戶端瀏覽器禁用了Cookie會怎么樣，我們會發(fā)現(xiàn)每一次刷新瀏覽器Set-Cookie都是不同的，而發(fā)送請求頭中也永遠不會出現(xiàn) Cookie標識。這個時候，我們會發(fā)現(xiàn)Session失效了（當然，微軟為了防止出現(xiàn)這種情況，允許我們在sessionState中設置 cookieless="true"，用URL來傳遞sessionid）。

二：Memcached Providers

我使用的Memcached客戶端是Memcached Providers，下載完畢后，你會發(fā)現(xiàn)Memcached Providers已經提供了對分布式Session的支持功能。如果你還不會使用Memcached Providers，請參考此文Memcached Tip 1：使用Memcached Providers。Memcached Providers提供的示例是直接將SESSION存儲在數(shù)據(jù)庫，我們可以通過配置來將SESSION支持存儲在分布式SESSION的內存中，即，將下文中的dbType由SQL修改為none。：

使用Memcached Providers提供的分布式Session沒有任何特別之處，因為Memcached Providers提供的SessionStateProvider類型實現(xiàn)的是ASP.NET中的 SessionStateStoreProviderBase這個抽象類，我們可以看到配置文件中指定了Session的處理類是 SessionStateProvider，所以，ASP.NET在接受到客戶端的請求后，會自覺滴使用SessionStateProvider來處理所有的SESSION，也正是這個類，完成了將SESSION讀取和存儲在Memcached中（如果設置了SQL，則會同步存儲到SQLSERVER數(shù)據(jù)庫）。

SESSION的設置和讀取與傳統(tǒng)沒有任何區(qū)別，讀：

 Session["sname2"] = "sluminjxxi";
 Session.Timeout = 2;

取：

 Response.Write(Session["sname2"]);

三：為什么要配置SQL

傳統(tǒng)的SESSION的缺點，在僅使用dbType為none配置的時候都會存在。如Memcached的內存到達上限的時候會怎么辦？Memcached使用LRU淘汰算法（最久未使用），在這里我們不需要去細究這個算法在Memcached內部到底是什么樣一個機制，我們只需要知道，在內存緊張的時候，即使SESSION時間未到，Memcached也有可能把它干掉。所以，保險的做法是，在Memcached之下，再加上 SQLSERVER的持久化保存。如果緩存命中的，直接取緩存，如果緩存沒命中的，則再到數(shù)據(jù)庫中確認一次。當然，這樣會帶來一些性能損耗，但是卻是更安全的做法。

Memcached Providers提供的下載文件中，提供了初始化SESSION的一些腳本，正確執(zhí)行后，它會生成如下一個表tblSessions，及若干存儲過程：

tblSessions保存的是就是單獨的Session，如下：

四：Memcached Providers的一個BUG

在當前的Memcached Providers（1.2版本）中關于SessionStateProvider（29520-TRUNK）是有一個BUG（我已提交到 codeplex，相信他們的下一個版本應該能得到修正）的。如果我們測試SESSION失效時間，發(fā)現(xiàn)只要經過一次刷新后，就永遠是20分鐘（即默認）。這源于在ReleaseItemExclusive這個重載方法中（該方法用于釋放對會話數(shù)據(jù)存儲區(qū)中項的鎖定），對于Session的重新存儲沒有加上過期時間，如下：

注釋掉的是Memcached Providers提供的源碼，而正確的應該是我修正過的上一條。使用修正過的DLL，一切圓滿了。

五：采用數(shù)據(jù)庫存儲SESSION的可擴展問題

隨著訪問量的進一步上升（當然，到了這種程度，說明網(wǎng)站做的很很成功，絕大部分的網(wǎng)站是不需要考慮這一步的），即便我們使用了Memcached作緩存，使用單一的SQLSERVER存儲SESSION仍舊帶來了性能問題，在這種情況下，我們對于數(shù)據(jù)庫的設計可以采用水平分區(qū)的架構，即根據(jù)某種算法（可以根據(jù)SESSIONID，或者用戶名等）將SESSION存儲到不同的數(shù)據(jù)庫中。這個時候，如果我們仍舊使用Memcached Providers，那么必須進一步修改源碼了，由原先支持單一SQLSERVER服務器，編程支持多個服務器。當然，如果不喜歡SQLSERVER，還可以修改為支持mysql、mongodb、任何自定義的KEY-VALUE框架等等，此為后話，暫且不表。

聲明：本網(wǎng)頁內容旨在傳播知識，若有侵權等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com