在asp.net中如何管理cache
介绍:
在我解释cache管理机制时 首先让我阐明下一个观念 IE下面的数据管理 每个人都会用不同的方法去解决如何在IE在管理数据 有的会提到用状态管理 有的提到的cache管理 这里我比较喜欢cache管理 因为本人比较喜 cache 这个词 但是状态管理和cache管理这两个在概念和意义上是不同的 下面就让我们来讨论下两都在各个方面的不同之处
虽然cache管理并不存在于Windows程序 但在web环境中已经得到巨大的应用 自从HTTP变成无协议以来 在WEB上要想分辨两个不同请求变得非常难 如何分辨如此多的请求变得非常重要 如果是同一请求 我们就可以把数据缓存起来供web上所有用户访问 减少数据重复进行物理加载
提供了几种方法来缓存数据在客户端和服务器端 但是我们经常为到底用哪种方式而感动苦恼 提供了以下三种实现方式
:Session; : Application : Cache objects 我们必须非常清楚它们之间的优势 这样才能充分利用它们的优势发挥在web程序中
背景
这篇文章中 我将简单涉及cache管理中的不同功能 在web程序中 我们为了避免因高并发产生的数据访问带来的性能问题 我们有必要把数据缓存于服务器端 使得后来的访问可以直接调用缓存数据 起到数据重用的作用
缓存能够帮忙我们提到服务质量的三个重要方面
性能 缓存数据达到数据重用 避免了重复的物理数据加载
可量测性 数据缓存后 减少了从服务器端加载数据
实用性 如果其它的系统或者是数据库发生死机 那么仍然可以从缓存中取得数据不受局部硬件的影响
在一个web 程序中 我们可以数据缓存 页面缓存等等 让我们来看下数据缓存在服务器端和客户端的不同之处
服务器端缓存:
Session状态管理:
session为每个人缓存数据 也就是说这样缓存的数据并不能同时供多人共享 限于为单个人缓存数据
状态管理有三种实现方式 分别是
:InProc:
它的数据存储在aspnet_wp exe 进程中 数据会因为IIS的重启而丢失
:StateServer :
较InProc不同的是 它可以存储于不同的服务器中
:SQLServer:
它的数据存储在数据库中 数据不会因为IIS的重启而丢失数据
后两种方法与InProc最大的区别在于 我们要确保缓存的数据是可序列化的 否则只能用于第一种方式 为此我们要仔细分析从而选出最适合自己的方式
下面是如何作用Session的代码片段
Code
string empNum = Request QueryString[ empnum ];
if (empNum != null)
{
string details = null;
if (Session[ EMP_DETAILS ] == null)
{
//Get Employee Details for employee number passed
string details = GetEmployeeDetails(Convert ToInt (empNum));
Session[ EMP_DETAILS ] = details;
}
else
{
details = Session[ EMP_DETAILS ];
}
//send it to the browser
Response Write(details);
}
ASP NET application
为我们提供了另外一种全局变量保存方法 Application对象 它也是面向所有用户 它的生命周期和应用程序一样 当应用程序初始化后它就开始重建 但它最大的缺点是没有相关数据过期的方法 此时就要用到cache管理
ASP NET cache
cache是我最喜欢用的机制 这也是为什么我喜欢说它的原因 它提供了键 值对应的方法 cache对应的命名空间是 System Web Caching 它的生命周期也依赖于应用程序 但它并不像session 这也是面向所有用户的 虽然cache看起来特别像application 但它最大的不同是提供了数据缓存失效控制方法以及数据缓存依赖管理 也就是说 在cache中我们可以非常容易的按照事先设定好的过期时间来让cache过期 删除cache 我们也可以根据缓存依赖关系来操作cache 当依赖的关系有改动时 此时cache也会自动失效 而这都是applicaion没法办到的
现在让我们看下中是如何支持cache的过期以及数据缓存依赖的
:缓存依赖
顾名思义它是指当事先设定的依赖关系发生变化时 cache 将会失效 在中提供了两种依赖关系
文件缓存依赖:当磁盘上的一个文件发生变化时自动让cache失效
下面是实例代码
object errorData;
//Load errorData from errors xml
CacheDependency fileDependency =
new CacheDependency(Server MapPath( errors xml ));
Cache Insert( ERROR_INFO errorData fileDependency);
键值缓存依赖 看起来和文件缓存非常像 不同之外就是这种依赖方式不同而已 当有多个cache信息之间互相关联时 一个cache信息的变化将会引起其它cache的失效 例如一个用户信息包含 编号 姓名 地址等 如果用户编号发生变化则cache失效 这种情况下 用户的基本信息就依赖于用户编号
下面是示例代码
string[] relatedKeys = new string[ ];
relatedKeys[ ] = EMP_NUM ;
CacheDependency keyDependency = new CacheDependency(null relatedKeys);
Cache[ EMP_NUM ] = ;
Cache Insert( EMP_NAME Shubhabrata keyDependency);
Cache Insert( EMP_ADDR Bhubaneswar keyDependency);
Cache Insert( EMP_SAL USD keyDependency);
:过期策略 从创建cache开始 一段时间后自动过期
示例代码
//Absolute Expiration
Cache Insert( EMP_NAME Shubhabrata null
DateTime Now AddDays( ) Cache NoSlidingExpiration);
//Sliding Expiration
Cache Insert( EMP_NAME Shubhabrata null
Cache NoAbsoluteExpiration TimeSpan FromSeconds( ));
ASP NET 页面输出缓存
有的时候在web站点中 有些页面在很长一段时间内都不会发生变化 例如一个招聘网站 它对于工资的描述文字一般不会经常更改 一般都是一个月更改一次 所以在这一个月内 用户看到的内容都是一样的 所有如果把数据缓存在服务器端并不是完美的解决方案 这里可以用页面输出缓存
下面是示例代码
<%@OutputCache Duration= VaryByParam= empNum
Location= Server %>
:客户端缓存
在上面的文章中 我讨论了些数据缓存在服务器端的方法 然而有的时候我们为了提高性能我们要把有些数据缓存到客户端 利用这种机制来达到缓解服务器压力 不过在客户端缓存数据会有各种不同的安全性问题 下面我说简要的说下相关内容
Cookies:cookies在WEB程序开发中应用的非常广泛 它可以非常方便的在客户端与服务器端相互访问 不过它有数据大小限制 最大为 K 所有用它经常是保存小数据 同时cookie对于失效的控制也支持的相当完美
下面是示例代码
if (this Request Cookies[ MY_NAME ] == null)
{
this Response Cookies Add(new HttpCookie( MY_NAME
Shubhabrata Mohanty ));
}
else
{
this Response Write(this Request Cookies[ MY_NAME ] Value);
}
ViewState:ViewState是一个全新的概念 它一般用于页面或者是控件中保留数据以供和服务端交通 在ASP中的 我们存储数据是用隐藏控件来完成（Hidden fields） ViewState也是这样用的 只不过它比隐藏控件更加安全性 所有的值都是经过hash处理的 如果你查看页面源代码 你都会看到ViewState的存在 一般ViewState不用来保存大的数据
下面是示例代码
protected void Page_Load(object sender EventArgs e)
{
if (this ViewState[ MY_NAME ] == null)
{
this ViewState[ MY_NAME ] = Shubhabrata Mohanty ;
}
//txtName is a TextBox control
this txtName Text = this ViewState[ MY_NAME ] ToString();
}
隐藏控件 Hidden fields:它是最简单的 不用多说
下面是示例代码
<! In ASP NET >
<asp:HiddenField ID= myHiddenField Value= Shubhabrata
runat= server />
<! In HTML >
lishixinzhi/Article/program/net/201311/12415
Storm代理
2023-08-29 广告
