|
马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有帐号?立即注册
x
其实net网页编程之所以在曾经独步天下,就是因为他的跨平台、安全性,这两方面,效率可不是net网页编程的强项,反而是他最短的一块挡板,虽然net总是用理论证明比.NET快。假如我们正在利用Session,那末构建高功能可扩大的ASP.NET网站,就必需办理散布式Session的架构,由于单服务器的SESSION处置才能会很快呈现功能瓶颈,这类成绩也被称之为Session同步。微软有本人的散布式Session的办理计划,那就是SessionStateServer,我们能够参考:
ASP.NETSessionStatePartitioning
http://blog.maartenballiauw.be/post/2008/01/23/ASPNET-Session-State-Partitioning.aspx
ASP.NETloadbalancingandASP.NETstateserver
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.ckuyun.com/fish-li/archive/2011/07/31/2123191.html,写的很NICE)。当扫瞄器再次哀求服务器举行会见的时分,它会在哀求HTTP头中到场以下的标识,我们能够看到,这个SESSIONID就是下面的SESSIONID:
扫瞄器和服务器间就是经由过程如许一种机制来确保用户SESSION的。
假如客户端扫瞄器禁用了Cookie会怎样,我们会发明每次革新扫瞄器Set-Cookie都是分歧的,而发送哀求头中也永久不会呈现Cookie标识。这个时分,我们会发明Session生效了(固然,微软为了避免呈现这类情形,同意我们在sessionState中设置cookieless="true",用URL来传送sessionid)。
二:MemcachedProviders
我利用的Memcached客户端是MemcachedProviders,下载终了后,你会发明MemcachedProviders已供应了对散布式Session的撑持功效。假如你还不会利用MemcachedProviders,请参考此文MemcachedTip1:利用MemcachedProviders。MemcachedProviders供应的示例是间接将SESSION存储在数据库,我们能够经由过程设置来将SESSION撑持存储在散布式SESSION的内存中,即,将下文中的dbType由SQL修正为none。:
利用MemcachedProviders供应的散布式Session没有任何出格的地方,由于MemcachedProviders供应的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的耐久化保留。假如缓存射中的,间接取缓存,假如缓存没射中的,则再到数据库中确认一次。固然,如许会带来一些功能消耗,可是倒是更平安的做法。
MemcachedProviders供应的下载文件中,供应了初始化SESSION的一些剧本,准确实行后,它会天生以下一个表tblSessions,及多少存储历程:
tblSessions保留的是就是独自的Session,以下:
四:MemcachedProviders的一个BUG
在以后的MemcachedProviders(1.2版本)中关于SessionStateProvider(29520-TRUNK)是有一个BUG(我已提交到codeplex,信任他们的下一个版本应当能失掉修改)的。假如我们测试SESSION生效工夫,发明只需经由一次革新后,就永久是20分钟(即默许)。这源于在ReleaseItemExclusive这个重载办法中(该办法用于开释对会话数据存储区中项的锁定),关于Session的从头存储没有加上过时工夫,以下:
正文失落的是MemcachedProviders供应的源码,而准确的应当是我修改过的上一条。利用修改过的DLL,统统美满了。
五:接纳数据库存储SESSION的可扩大成绩
跟着会见量的进一步上升(固然,到了这类水平,申明网站做的很很乐成,尽年夜部分的网站是不必要思索这一步的),即使我们利用了Memcached作缓存,利用单一的SQLSERVER存储SESSION仍然带来了功能成绩,在这类情形下,我们关于数据库的计划能够接纳程度分区的架构,即依据某种算法(能够依据SESSIONID,大概用户名等)将SESSION存储到分歧的数据库中。这个时分,假如我们仍然利用MemcachedProviders,那末必需进一步修正源码了,由本来撑持单一SQLSERVER服务器,编程撑持多个服务器。固然,假如不喜好SQLSERVER,还能够修正为撑持mysql、mongodb、任何自界说的KEY-VALUE框架等等,此为后话,临时不表。
语言是不是不是最重要的? |
|