如果我們正在使用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頭給用戶端：
浏覽器和伺服器間就是通過這樣一種機制來確定使用者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架構等等，此為後話，暫且不表。
本系列的前篇：
1：
ASP.NET性能優化之建構自定義檔案緩存2：
ASP.NET性能優化之讓浏覽器緩存動态網頁3：
ASP.NET性能優化之減少請求4：
ASP.NET性能優化之反向代理緩存5：
ASP.NET性能優化之局部緩存
本文基于
Creative Commons Attribution 2.5 China Mainland License釋出，歡迎轉載，演繹或用于商業目的，但是必須保留本文的署名
http://www.cnblogs.com/luminji（包含連結）。如您有任何疑問或者授權方面的協商，請給我留言。