若是咱們正在使用Session，那麼構建高性能可擴展的ASP.NET網站，就必須解決分佈式Session的架構，由於單服務器的SESSION處理能力會很快出現性能瓶頸，這類問題也被稱之爲Session同步。微軟有本身的分佈式Session的解決方案，那就是SessionStateServer，咱們能夠參考：html
ASP.NET Session State Partitioning http://blog.maartenballiauw.be/post/2008/01/23/ASPNET-Session-State-Partitioning.aspxmysql
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做爲分佈式的緩存服務器已經被普遍應用在網站建設中。sql
一：Session的機制mongodb
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框架等等，此爲後話，暫且不表
轉：http://www.cnblogs.com/luminji/archive/2011/11/03/2195704.html