[转载]ASP.NET利用Memcached的分布式Session来提升性能 - IT青藤屋 - 青藤园

[转载]ASP.NET利用Memcached的分布式Session来提升性能 – IT青藤屋 – 青藤园.

摘要:很多时候,我们在使用ASP.NET的Session都是 将Session保存到网站进程中去,或者将Session保存到SQLServer或stateserver中,当然,一般情况下,这种方法肯定能满足 要求了。但是,单服务器存储Session始终会随着应用规模的扩大而出现瓶颈,这时候我们就需要搭建分布式Session了,下面这篇文章就是通过 Memcached的分布式特性来实现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的设置和读取与传统没有任何区别,读:

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

取:

1
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

赞(0) 打赏
分享到: 更多 (0)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏