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

如果我們正在使用Session，那麼構建高效能可擴充的ASP.NET網站，就必須解決分布式Session的架構，因為單伺服器的 SESSION處理能力會很快出現效能瓶頸，這類問題也被稱之為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作為分布式的快取服務器已經被廣泛應用在網站建設中。

一：Session的機制

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

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

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

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

二：Memcached Providers

我使用的Memcached用戶端是Memcached Providers，下載完畢後，你會發現Memcached Providers已經提供了對分布式Session的支援功能。如果你還不會使用Memcached Providers，請參考此文Memcached Tip 1：使用Memcached Providers。Memcached Providers提供的樣本是直接將SESSION儲存在資料庫，我們可以通過配置來將SESSION支援儲存在分布式SESSION的記憶體中，即，將下文中的dbType由SQL修改為none。：

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

SESSION的設定和讀取與傳統沒有任何區別，讀：

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

取：

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

三：為什麼要配置SQL

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

Memcached Providers提供的下載檔案中，提供了初始化SESSION的一些指令碼，正確執行後，它會產生如下一個表tblSessions，及若干預存程序：

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

四：Memcached Providers的一個BUG

在當前的Memcached Providers（1.2版本）中關於SessionStateProvider（29520-TRUNK）是有一個BUG（我已提交到 codeplex，相信他們的下一個版本應該能得到修正）的。如果我們測試SESSION失效時間，發現只要經過一次重新整理後，就永遠是20分鐘（即預設）。這源於在ReleaseItemExclusive這個重載方法中（該方法用於釋放對會話資料存放區區中項的鎖定），對於Session的重新儲存沒有加上到期時間，如下：

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

五：採用資料庫儲存SESSION的可擴充問題

隨著訪問量的進一步上升（當然，到了這種程度，說明網站做的很很成功，絕大部分的網站是不需要考慮這一步的），即便我們使用了Memcached作緩衝，使用單一的SQLSERVER儲存SESSION仍舊帶來了效能問題，在這種情況下，我們對於資料庫的設計可以採用水平資料分割的架構，即根據某種演算法（可以根據SESSIONID，或者使用者名稱等）將SESSION儲存到不同的資料庫中。這個時候，如果我們仍舊使用Memcached Providers，那麼必須進一步修改源碼了，由原先支援單一SQLSERVER伺服器，編程支援多個伺服器。當然，如果不喜歡SQLSERVER，還可以修改為支援mysql、mongodb、任何自訂的KEY-VALUE架構等等，此為後話，暫且不表。