标签归档:ASP.NET

.Net架构网站遇到大表的处理办法

最近做的web2.0网站本身遇到一个大表(2000万rows左右),因为对于performance,web本身可用性的考虑,必须想办法boost perf.这种情况应该都用partition来搞定了,这也符合分治等算法的思想,想办法降低问题本身的复杂度,然后在一个一个解决。

mysql中一般到100万操作就有点麻烦了,index要好好的做。这里还遇到了一个文本检索问题,MyIASM storage engine里面有个full-text index,但是不知道它对于中文支持如何,而且不清楚它是怎么分词的,不大清楚后台逻辑,Mysql这种index limitation很多,很难scalable,所以基本上直接考虑用search engine那一套。直接上了lucene+solr+solrsharp.小表like还可以忽悠忽悠,大点就慢的如老牛……

Partition通过了解发现解决方案倒是不少,以前做过了解过这方面知识储备。

对hivedb,hscale等都没想过要尝试,发现。net在使用open source很多都不是很舒服。

最开始尝试了mysql partition,一开始听起来方法这种方案很Perfect!是mysql解决horizontal partioning的很好方案,等document看完了,发现5.1版本的partion limitation太多了,只能适合某些特性的场景,例如按照用户id做split;普通那种非unique key,primary key是很难搞定的,简单方法是给表本身不添加任何主键,自己来实现主键生成机制。这样仿佛可以了,但是通过explain partitions来做下analysis,发现结果定位具体parition不好,这就很难降低IO本身的高成本了。没有通过具体测试不知道可能是 explain partition本身不准确原因还是……

mysql partition还有一个很大的弊病,就是很难跨机器,当然如何能够把Mysql存储做成分布式,也还好,但是这个技术代价都上了不少档次,risk过高了,只能算是下下策了,备用好了。这些不爽的地方导致偶们直接抛弃了这种方案,直接用手工切分来搞定这种问题,我想这也是大部分这种需求的常见 solution把。

手工切分本身技术还比较简单,

就是要考虑表的编码,管理等多个方面,以及如何快速定位到可能的partition,这些在设计方面都应该注意了。

而且对于多partitions的结果,应该使用多线程等并发,同步技术来提高perf.这里的partition还做到支持对某一个partition做进一步切分,这样切分到每一个partition块尽量表中数据在50万以下,这样加上db index,速度应该能够满足一定的需求的,手工切分本身很容易scale out,可以把表放在不同的机器上等等load balance方法来scale.回想感觉最有意思还是表编码自身的考虑有点意思,我很大程度的灵感来源于IP地址的划分,因为这个表自身增长速度会很慢,所以采用unsigned int来搞定,43亿来表示2000万还是小意思嘛。我主要是通过前缀+长度来定义表的标识。1,2,3前缀可以让给数据比较密集的表,因为它们可以支持10位,其它就用9位来表示,可能有些不再切分范围内的就让他们从0开始增长把。这里partition list本身维护可以序列化到filesystem中,每次Load class时候deserialize一下,然后就是本身partition如何快速定位就需要用点复杂点的data stuctures了。

出处:IT专家网论坛

ASP.NET安全解决方案

在开发Web程序中,我们可以选择用自己的方法来实现安全的策略,或者可以购买第三方的安全代码和产品,不管怎么样,都是要很大的花费的,幸好在.NET Framework中已经内置了安全的解决方案。ASP.NET和 .NET Framework 联合IIS为Web应用程序安全提供了一个基础结构。它的一个很明显的优势在于我们不必再编写自己的安全架构,我们可以利用.NET安全架构的内置的特性,而且整个安全的架构是经过测试和时间的考验了的。

.NET安全架构包含了很多的类,这些类用来处理身份验证,授权,基于角色的授权,假冒(Impersonation),代码访问安全,还包含了一个用于构建自定义解决方案的基本架构。

本篇我们主要谈论下面的一些话题:

ASP.NET安全架构的主要功能

身份验证和授权

安全上下文中的标识和主体

身份验证模块的运行

授权模块的运行

下面就开始:

一 ASP.NET实现安全的过程

ASP.NET 安全架构分为几个关键的安全过程:身份验证,授权,假冒,加密提供提供了必需的功能。具体看看一些解释:

身份验证–指明是谁再访问我们的站点

授权—-谁可以对哪些资源操作和访问?访问站点的用户是否被授权使用他所请求的资源?

假冒—-准备假冒什么角色?(注:假冒不是贬义词,不是我们常说的假冒商品的假冒,因为不同的用户角色有不同的权限,如果我们当前的用户无法访问某一特定的资源,我们就可以让想访问特定资源的用户假冒,更确切的说是模仿有权限访问特定资源的用户,简言之:用户A想访问C资源,但是没有权限,但是用户B可以访问,所以A和B商量,A就用B的身份访问。具体的以后讲解)

下面我们具体看看每个安全的过程:

1.身份验证

身份验证是揭示用户标识(注:标识的概念我们后面马上就讲的,简言之,用户的ID 和名称)并判断标识真实性的过程。很好理解,举个例子(大家注意例子中的一些术语):我们要取参加一个会议,我们就会取登记提供我们的一些证件即标识(表明我们的身份),一旦标识被确认,我们就会得到会议通行证,我们就可以带着通行证参加会议。而且会议中的每个人都可以通过我们的通行证了解我们的一些信息,如我们的名字,公司。身份验证就是:一旦标识被确定,我们就会得到一个可以识别我们的令牌,所以,再一个特定的区域内,不管我们在哪里,我们的标识都可以被识别。

在ASP.NET中,有4中身份验证的模式:

Widows身份验证(Windows Authentication)

Forms身份验证(Form Authentication)

Passpot身份验证(Passport Authentication)

自定义身份验证

对于每一种身份验证,用户都需要在登录的时候提供凭证,一旦标识被核实,用户就会获得一个身份验证令牌,在Forms验证中,整个令牌就是FormsAuthenticationTicket,整个令牌就放在 cookie中,每次请求资源的时候,令牌就会提供用户的标识信息。

2.授权

我们接着拿之前的那个会议的例子来看,授权就是表明我们可以做什么。进入会议厅以后,发现有很多不同的会议,专家级的,普通级的,不同人参加不同级别的会议。而且有些人可以参观整个会议厅,但是有些人只能在展览厅参观。这就是权限的不同而导致的。

所以,授权就是:以我们的标识信息为参考,批准或者拒绝访问我们请求的资源。还有一点要注意的是:我们一般是常用的是基于角色的授权,就是把用户分为一组一组,然后给每组不同的角色。

假冒

假冒是在其他用户标识的上下文中执行代码的过程。在默认情况下,所有的ASP.NET代码都是在Domain/ASPNET用户账户下执行的,要利用其他的标识执行代码,假冒其他的标识,我们应该利用.NET安全架构中的内置的假冒的功能。它允许我们指定执行代码的用户账户,比如不同于 Domain/ASPNET的预定用户账户。我们既可以利用ASP.NET中身份验证功能来验证用户,也可以利用标准的Windows身份验证来验证用户。

然后我们可以利用我们的凭证,或者利用执行代码的预定义用户账户来设置所假冒的账户。

假冒还允许我们在不使用ASP.NET提供的身份验证和授权功能的情况下提供身份验证和授权:我们可以利用用户账户和他们相关权限支持Windows和IIS管理身份验证和授权。

假冒通常用于提供访问控制,比如授权,一个应用程序可以访问它所假冒的的用户可以访问的任何资源。例如,默认情况下,Domain/ASPNET用户不能对文件系统进行读写操作的,所以这个用户账户也无法在Enterprise Services中执行事务处理。但是利用假冒,用户就可以通过假冒一个特定的Windows账户完成这些事情,因为这个特定的账户有这个权限。因此,我们就可以保证一些用户可以对文件系统进行读写操作,而其他的一些用户仅仅执行读的操作。

好了,上面讲了很多,我们现在就来小结一下,看看如何把身份验证,授权,假冒一起用于Web程序中。

当用户首次访问Web站点时,他们是匿名用户,我们不知道他们的标识,除非对他们进行身份验证,否则我们以后还是不知道他们的标识。当用户请求非安全的资源时,他们可以自动的访问这个资源(这就是非安全资源的定义)

当用户请求安全的受保护的资源时,就要如下步骤:

1.请求被发送到 Web服务器,由于此时这个用户标识还有被确认,所以用户就被重定向到登录页面

2.用户提供凭证,身份验证就对凭证进行验证和审核

3.如果用户凭证合法,就可以访问资源,否则,就不能。

当用户请求安全的资源,但是该资源有特定权限的用户才能访问,就会发生下面步骤:

1.请求被发送到 Web服务器,由于此时这个用户标识还有被确认,所以用户就被重定向到登录页面

2.用户提供凭证,身份验证就对凭证进行验证和审核

3.把用户的凭证或者角色与被允许的用户或者角色进行比较,如果用户在列表中,那么他们就被准许访问这个资源,否则,拒绝。

如果启用了假冒,那么在这两种情况下,假冒都会发生。默认情况下,假冒是禁止的,可以修改配置文件添加元素启用:

以下为引用的内容:

<configuration>

<system.web>

<identity impersonate=”true” userName=”Xiaoyang/User” password=”xiaoyang”/>

</system.web>

</configuration>

在中,把impersonate特性设置为true,拿userName和 password设为要假冒的用户账户。如果假冒被启用,那么被审核的就是假冒的用户标识的凭证,而不是提交的凭证。这两种凭证有可能相同,需要注意的是:假冒是利用Web服务器中已有的用户访问,如IUser用户

Microsoft .NET Pet Shop 4 架构与技术分析

1.项目概述与架构分析
微软刚推出了基于ASP.NET 2.0下的Pet Shop 4, 该版本有了一个全新的用户界面。是研究ASP.NET 2.0的好范例啊,大家都知道,一直以来,在.NETJava之间争论不休,到底使用哪个平台开发的企业级应用性能最好、结构最优、生产力最高。为了用事实说话,通过对项目各方面的性能评估进而在比较.NETJava的高下。用户做比较的这个项目就是Petshop。正因为Petshop肩负着上面所说的重任,各方面必须是最优的,架构设计应该是经过慎重考虑的。所以其一经推出,便成为了开发者、架构师等人学习、研究的典范。

日前微软推出了基于.NET Framework 2.0开发的Petshop 4。新的Petshop4实现了与Petshop 3相同甚至更多的特性,由于采用了Master PagesMembership,以及ProfileSqlCacheDependency,但是代码量却减少了四分之一。同时,在事务、数据缓存、安全方面使用了.NET 2.0附带的特性,构建了一个灵活的最佳实践的应用程序。

1

他们利用了Project Conversion Wizard把项目从ASP.NET 1.1移植到了ASP.NET 2.0,然后做了以下改动:

1.用System.Transactions代替了原来的Serviced Components提供的事务功能

代码实现:PetShop.BLL.OrderSynchronous public void Insert(PetShop.Model.OrderInfo order)

2.用强类型的范型集合代替了原来的弱类型集合

public IList<ProductInfo> GetProductsByCategory(string category)

{

// Return new if the string is empty

if (string.IsNullOrEmpty(category))

return new List<ProductInfo>();

// Run a search against the data store

return dal.GetProductsByCategory(category);

}

3.采用ASP.NET 2.0 Membership来做认证和授权

4.创建了针对Oracle 10gCustom ASP.NET 2.0 Membership Provider

5.利用ASP.NET 2.0Custom Oracle SQL Server Profile Providers 做用户状态管理,包括购物车等

6.采用了Master Pages,取代了原来的用户控件,来实现统一的界面效果

7.使用了ASP.NET 2.0 Wizard控件实现check-out

8.使用了SqlCacheDependency来实现数据库层次的缓存更新(cache invalidation)功能

9.使用了消息队列来实现异时订单处理。

2.整体架构:

Pet shop 架构图
数据库:(暂略)

项目列表:从整体可以看出,Pet Shop 4的项目体系已经很庞大,考虑的方面也较3.0更全面复杂。

pet shop 解决方案

序号

项目名称

描述

1

BLL

业务逻辑层

2

CacheDependencyFactory

缓存依赖类的工厂类

3

WEB

表示层

4

DALFactory

数据层的抽象工厂

5

DBUtility

数据访问类组件

6

IBLLStrategy

同步/异步策略接口

7

ICacheDependency

缓存依赖类接口

8

IDAL

数据访问层接口定义

9

IMessaging

异时处理消息队列接口定义

10

IProfileDAL

Profile的数据访问层接口定义

11

Membership

Membership认证和授权管理

12

MessagingFactory

异时处理消息队列的抽象工厂

13

Model

业务实体

14

MSMQMessaging

异时处理消息队列的实现

15

OracleDAL

Oracle数据访问层

16

OracleProfileDAL

OracleProfile Providers

做用户状态管理,包括购物车等

17

OrderProcessor

后台处理进程,处理订单队列

18

Profile

Profile的数据访问层

19

ProfileDALFactory

ProfileDAL的工厂类(反射创建ProfileDAL)

20

SQLProfileDAL

SQL Server Profile Providers

做用户状态管理,包括购物车等

21

SQLServerDAL

SQLServer数据访问层

22

TableCacheDependency

缓存依赖实现类

项目分解

由于整体已经有22个项目,所以,对于初学者一看就晕了,所以,我做了分解,可以大体上分几块去理解。

序号

项目名称

描述

1

WEB

表示层

2

Model

业务实体

3

BLL

业务逻辑层

4

DALFactory

数据层的抽象工厂

5

IDAL

数据访问层接口定义

6

SQLServerDAL

SQLServer数据访问层

7

OracleDAL

Oracle数据访问层

8

DBUtility

数据库访问组件基础类

9

CacheDependencyFactory

缓存依赖类的工厂类

10

ICacheDependency

缓存依赖类接口

11

TableCacheDependency

缓存依赖实现类

12

IBLLStrategy

同步/异步处理策略接口(实现在bll根据配置反射选择)

13

MessagingFactory

异时处理消息队列的抽象工厂

14

IMessaging

异时处理消息队列接口定义

15

MSMQMessaging

异时处理消息队列的实现

16

Profile

Profile的数据访问层

17

ProfileDALFactory

ProfileDAL的工厂类(反射创建ProfileDAL)

18

IProfileDAL

Profile的数据访问层接口定义

19

OracleProfileDAL

OracleProfile Providers

做用户状态管理

20

SQLProfileDAL

SQL Server Profile Providers

做用户状态管理

21

Membership

Membership认证和授权管理

22

OrderProcessor

后台处理进程,处理订单队列


Pet Shop 项目分解

3Petshop 4中的设计模式

工厂模式:

首当其冲的就是工厂模式,很容易就可以看出来,也是应用最多的。

DALFactory:数据访问层的抽象工厂(决定创建哪种数据库类型的数据访问层。可以选择:SQLServerOracle

CacheDependencyFactory缓存依赖类的工厂类。(创建具体表的缓存依赖)

MessagingFactory 异时处理消息队列的抽象工厂(反射创建具体的异时处理类

ProfileDALFactoryProfileDAL的工厂类(反射选择创建Oracle SQL ServerProfileDAL)

策略模式: IorderStrategy

策略模式: IorderStrategy

中介模式

CategoryDataProxy ItemDataProxy ProductDataProxy

中介模式

暂时只看了这么多,以后有时间继续分解,如果你有不同的见解或经验,也请写下来,好让大家来共同学习,共同探讨,共同进步。

(作者:李天平 转载请注明)

具体介绍可以参看MSDN

.NET Pet Shop 4: Migrating an ASP.NET 1.1 Application to 2.0

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/bdasamppet4.asp

下载

http://download.microsoft.com/download/8/0/1/801ff297-aea6-46b9-8e11-810df5df1032/Microsoft%20.NET%20Pet%20Shop%204.0.msi

ASP.NET 缓存 方法和最佳实践

在 ASP.NET 提供的许多特性中,缓存支持无疑是我最欣赏的特性,我这样说当然是有充分理由的。相比 ASP.NET 的所有其他特性,缓存对应用程序的性能具有最大的潜在影响,利用缓存和其他机制,ASP.NET 开发人员可以接受使用开销很大的控件(例如,DataGrid)构建站点时的额外开销,而不必担心性能会受到太大的影响。为了在应用程序中最大程度地利用缓存,您应该考虑在所有程序级别上都实现缓存的方法。

Steve 的缓存提示

尽早缓存;经常缓存

您应该在应用程序的每一层都实现缓存。向数据层、业务逻辑层、UI 或输出层添加缓存支持。内存现在非常便宜 — 因此,通过以智能的方式在整个应用程序中实现缓存,可以获得很大的性能提高。

缓存可以掩盖许多过失

缓存是一种无需大量时间和分析就可以获得“足够良好的”性能的方法。这里再次强调,内存现在非常便宜,因此,如果您能通过将输出缓存 30 秒,而不是花上一整天甚至一周的时间尝试优化代码或数据库就可以获得所需的性能,您肯定会选择缓存解决方案(假设可以接受 30 秒的旧数据)。缓存正是那些利用 20% 付出获得 80% 回报的特性之一,因此,要提高性能,应该首先想到缓存。不过,如果设计很糟糕,最终却有可能带来不良的后果,因此,您当然也应该尽量正确地设计应用程序。但如果您只是需要立即获得足够高的性能,缓存就是您的最佳选择,您可以在以后有时间的时候再尽快重新设计应用程序。

页面级输出缓存

作为最简单的缓存形式,输出缓存只是在内存中保留为响应请求而发送的 HTML 的副本。其后再有请求时将提供缓存的输出,直到缓存到期,这样,性能有可能得到很大的提高(取决于需要多少开销来创建原始页面输出 – 发送缓存的输出总是很快,并且比较稳定)。

实现

要实现页面输出缓存,只要将一条 OutputCache 指令添加到页面即可。

<%@ OutputCache Duration="60" VaryByParam="*" %>

如同其他页面指令一样,该指令应该出现在 ASPX 页面的顶部,即在任何输出之前。它支持五个属性(或参数),其中两个是必需的。

Duration 必需属性。页面应该被缓存的时间,以秒为单位。必须是正整数。
Location 指定应该对输出进行缓存的位置。如果要指定该参数,则必须是下列选项之一:Any、Client、Downstream、None、Server 或 ServerAndClient。
VaryByParam 必需属性。Request 中变量的名称,这些变量名应该产生单独的缓存条目。”none” 表示没有变动。”*” 可用于为每个不同的变量数组创建新的缓存条目。变量之间用 “;” 进行分隔。
VaryByHeader 基于指定的标头中的变动改变缓存条目。
VaryByCustom 允许在 global.asax 中指定自定义变动(例如,”Browser”)。

利用必需的 Duration 和 VaryByParam 选项的组合可以处理大多数情况。例如,如果您的产品目录允许用户基于 categoryID 和页变量查看目录页,您可以用参数值为 “categoryID;page” 的 VaryByParam 将产品目录缓存一段时间(如果产品不是随时都在改变,一小时还是可以接受的,因此,持续时间是 3600 秒)。这将为每个种类的每个目录页创建单独的缓存条目。每个条目从其第一个请求算起将维持一个小时。

VaryByHeader 和 VaryByCustom 主要用于根据访问页面的客户端对页面的外观或内容进行自定义。同一个 URL 可能需要同时为浏览器和移动电话客户端呈现输出,因此,需要针对不同的客户端缓存不同的内容版本。或者,页面有可能已经针对 IE 进行了优化,但需要能针对 Netscape 或 Opera 完全降低优化(而不仅仅是破坏页面)。后一个例子非常普遍,我们将提供一个说明如何实现此目标的示例:

示例: VaryByCustom 用于支持浏览器自定义

为了使每个浏览器都具有单独的缓存条目,VaryByCustom 的值可以设置为 “browser”。此功能已经内置在缓存模块中,并且将针对每个浏览器名称和主要版本插入单独的页面缓存版本。

<%@ OutputCache Duration="60" VaryByParam="None" VaryByCustom="browser"  %>

片段缓存,用户控件输出缓存

缓存整个页面通常并不可行,因为页面的某些部分是针对用户定制的。不过,页面的其他部分是整个应用程序共有的。这些部分最适合使用片段缓存和用户控件进行缓存。菜单和其他布局元素,尤其是那些从数据源动态生成的元素,也应该用这种方法进行缓存。如果需要,可以将缓存的控件配置为基于对其控件(或其他属性)的更改或由页面级输出缓存支持的任何其他变动进行改变。使用同一组控件的几百个页面还可以共享那些控件的缓存条目,而不是为每个页面保留单独的缓存版本。

实现

片段缓存使用的语法与页面级输出缓存一样,但其应用于用户控件(.ascx 文件)而不是 Web 窗体(.aspx 文件)。除了 Location 属性,对于 OutputCache 在 Web 窗体上支持的所有属性,用户控件也同样支持。用户控件还支持名为 VaryByControl 的 OutputCache 属性,该属性将根据用户控件(通常是页面上的控件,例如,DropDownList)的成员的值改变该控件的缓存。如果指定了 VaryByControl,可以省略 VaryByParam。最后,在默认情况下,对每个页面上的每个用户控件都单独进行缓存。不过,如果一个用户控件不随应用程序中的页面改变,并且在所有页面都使用相同的名称,则可以应用 Shared=”true” 参数,该参数将使用户控件的缓存版本供所有引用该控件的页面使用。

示例

<%@ OutputCache Duration="60" VaryByParam="*" %>

该示例将缓存用户控件 60 秒,并且将针对查询字符串的每个变动、针对此控件所在的每个页面创建单独的缓存条目。

<%@ OutputCache Duration="60" VaryByParam="none"
VaryByControl="CategoryDropDownList" %>

该示例将缓存用户控件 60 秒,并且将针对 CategoryDropDownList 控件的每个不同的值、针对此控件所在的每个页面创建单独的缓存条目。

<%@ OutputCache Duration="60" VaryByParam="none" VaryByCustom="browser"
Shared="true %>

最后,该示例将缓存用户控件 60 秒,并且将针对每个浏览器名称和主要版本创建一个缓存条目。然后,每个浏览器的缓存条目将由引用此用户控件的所有页面共享(只要所有页面都用相同的 ID 引用该控件即可)。

缓存 API,使用 Cache 对象

页面级和用户控件级输出缓存的确是一种可以迅速而简便地提高站点性能的方法,但是在 ASP.NET 中,缓存的真正灵活性和强大功能是通过 Cache 对象提供的。使用 Cache 对象,您可以存储任何可序列化的数据对象,基于一个或多个依赖项的组合来控制缓存条目到期的方式。这些依赖项可以包括自从项被缓存后经过的时间、自从项上次被访问后经过的时间、对文件和/或文件夹的更改以及对其他缓存项的更改,在略作处理后还可以包括对数据库中特定表的更改。

Cache 中存储数据

在 Cache 中存储数据的最简单的方法就是使用一个键为其赋值,就像 HashTable 或 Dictionary 对象一样:

Cache["key"] = “value”;

这种做法将在缓存中存储项,同时不带任何依赖项,因此它不会到期,除非缓存引擎为了给其他缓存数据提供空间而将其删除。要包括特定的缓存依赖项,可使用 Add() 或 Insert() 方法。其中每个方法都有几个重载。Add() 和 Insert() 之间的唯一区别是,Add() 返回对已缓存对象的引用,而 Insert() 没有返回值(在 C# 中为空,在 VB 中为 Sub)。

示例

Cache.Insert("key", myXMLFileData, new
System.Web.Caching.CacheDependency(Server.MapPath("users.xml")));

该示例可将文件中的 xml 数据插入缓存,无需在以后请求时从文件读取。 CacheDependency 的作用是确保缓存在文件更改后立即到期,以便可以从文件中提取最新数据,重新进行缓存。如果缓存的数据来自若干个文件,还可以指定一个文件名的数组。

Cache.Insert("dependentkey", myDependentData, new
System.Web.Caching.CacheDependency(new string[] {}, new string[]
{"key"}));

该示例可插入键值为 “key” 的第二个数据块(取决于是否存在第一个数据块)。如果缓存中不存在名为 “key” 的键,或者如果与该键相关联的项已到期或被更新,则 “dependentkey” 的缓存条目将到期。

Cache.Insert("key", myTimeSensitiveData, null,
DateTime.Now.AddMinutes(1), TimeSpan.Zero);

绝对到期:此示例将对受时间影响的数据缓存一分钟,一分钟过后,缓存将到期。注意,绝对到期和滑动到期(见下文)不能一起使用。

Cache.Insert("key", myFrequentlyAccessedData, null,
System.Web.Caching.Cache.NoAbsoluteExpiration,
TimeSpan.FromMinutes(1));

滑动到期:此示例将缓存一些频繁使用的数据。数据将在缓存中一直保留下去,除非数据未被引用的时间达到了一分钟。注意,滑动到期和绝对到期不能一起使用。

更多选项

除了上面提到的依赖项,我们还可以指定项的优先级(依次为 low、high、NotRemovable,它们是在 System.Web.Caching.CacheItemPriority 枚举中定义的)以及当缓存中的项到期时调用的 CacheItemRemovedCallback 函数。大多数时候,默认的优先级已经足够了 — 缓存引擎可以正常完成任务并处理缓存的内存管理。CacheItemRemovedCallback 选项考虑到一些很有趣的可能性,但实际上它很少使用。不过,为了说明该方法,我将提供它的一个使用示例:

CacheItemRemovedCallback 示例

System.Web.Caching.CacheItemRemovedCallback callback = new System.Web.Caching.CacheItemRemovedCallback (OnRemove);
Cache.Insert("key",myFile,null,
System.Web.Caching.Cache.NoAbsoluteExpiration,
TimeSpan.Zero,
System.Web.Caching.CacheItemPriority.Default, callback);
. . .
public static void OnRemove(string key,
object cacheItem,
System.Web.Caching.CacheItemRemovedReason reason)
{
AppendLog("The cached value with key '" + key +
"' was removed from the cache.  Reason: " +
reason.ToString());
}

该示例将使用

AppendLog()

方法(这里不讨论该方法,请参阅 Writing Entries to Event Logs)中定义的任何逻辑来记录缓存中的数据到期的原因。通过在从缓存中删除项时记录这些项并记录删除的原因,您可以确定是否在有效地使用缓存或者您是否可能需要增加服务器上的内存。注意,callback 是一个静态(在 VB 中为 Shared)方法,建议使用该方法的原因是,如果不使用它,保存回调函数的类的实例将保留在内存中,以支持回调(对 static/Shared 方法则没有必要)。

该特性有一个潜在的用处 — 在后台刷新缓存的数据,这样用户永远都不必等待数据被填充,但数据始终保持相对较新的状态。但实际上,此特性并不适用于当前版本的缓存 API,因为在从缓存中删除缓存的项之前,不触发或不完成回调。因此,用户将频繁地发出尝试访问缓存值的请求,然后发现缓存值为空,不得不等待缓存值的重新填充。我希望在未来的 ASP.NET 版本中看到一个附加的回调,可以称为 CachedItemExpiredButNotRemovedCallback,如果定义了该回调,则必须在删除缓存项之前完成执行。

缓存数据引用模式

每当我们尝试访问缓存中的数据时,都应该考虑到一种情况,那就是数据可能已经不在缓存中了。因此,下面的模式应该普遍适用于您对缓存的数据的访问。在这种情况下,我们假定已缓存的数据是一个数据表。

public DataTable GetCustomers(bool BypassCache)
{
string cacheKey = "CustomersDataTable";
object cacheItem = Cache[cacheKey] as DataTable;
if((BypassCache) || (cacheItem == null))
{
cacheItem = GetCustomersFromDataSource();
Cache.Insert(cacheKey, cacheItem, null,
DateTime.Now.AddSeconds(GetCacheSecondsFromConfig(cacheKey),
TimeSpan.Zero);
}
return (DataTable)cacheItem;
}

关于此模式,有以下几点需要注意:

  • 某些值(例如,cacheKey、cacheItem 和缓存持续时间)是一次定义的,并且只定义一次。
  • 可以根据需要跳过缓存 — 例如,当注册一个新客户并重定向到客户列表后,最好的做法可能就是跳过缓存,用最新数据重新填充缓存,该数据包括新插入的客户。
  • 缓存只能访问一次。这种做法可以提高性能,并确保不会发生 NullReferenceExceptions,因为该项在第一次被检查时是存在的,但第二次检查之前就已经到期了。
  • 该模式使用强类型检查。C# 中的 “as” 运算符尝试将对象转换为类型,如果失败或该对象为空,则只返回 null(空)。
  • 持续时间存储在配置文件中。在理想的情况下,所有的缓存依赖项(无论是基于文件的,或是基于时间的,还是其他类型的依赖项)都应该存储在配置文件中,这样就可以进行更改并轻松地测量性能。我还建议您指定默认缓存持续时间,而且,如果没有为所使用的 cacheKey 指定持续时间,就让 GetCacheSecondsFromConfig() 方法使用该默认持续时间。

相关的代码示例是一个 helper 类,它将处理上述所有情况,但允许通过一行或两行代码访问缓存的数据。请下载 CacheDemos.msi

小结

缓存可以使应用程序的性能得到很大的提高,因此在设计应用程序以及对应用程序进行性能测试时应该予以考虑。应用程序总会或多或少地受益于缓存,当然有些应用程序比其他应用程序更适合使用缓存。对 ASP.NET 提供的缓存选项的深刻理解是任何 ASP.NET 开发人员应该掌握的重要技巧。

Steven A. Smith 作为 Microsoft ASP.NET最有价值的专家,是 ASPAlliance.com 的总裁,也是该公司的所有者。他还是 ASPSmith Ltd(一家以 .NET 为中心的培训公司)的所有者和首席讲师。他撰写了两本书 — ASP.NET Developer’s CookbookASP.NET By Example,并且在 MSDN? 杂志和 AspNetPRO 杂志上发表文章。Steve 每年都要在几个会议上进行演讲,是 INETA Speaker’s Bureau 的成员。Steve 拥有工商管理硕士学位和计算机科学工程的理学学士学位。如果希望与 Steve 联系,请将电子邮件发送至 ssmith@aspalliance.com

ASP.NET 缓存概述

ASP.NET 缓存概述 通常,应用程序可以将那些频繁访问的数据,以及那些需要大量处理时间来创建的数据存储在内存中,从而提高性能。例如,如果应用程序使用复杂的逻 辑来处理大量数据,然后再将数据作为用户频繁访问的报表返回,避免在用户每次请求数据时重新创建报表可以提高效率。同样,如果应用程序包含一个处理复杂数 据但不需要经常更新的页,则在每次请求时服务器都重新创建该页会使工作效率低下。

在这些情况下,为了帮助您提高应用程序的性能,ASP.NET 使用两种基本的缓存机制来提供缓存功能。第一种机制是应用程序缓存,它允许您缓存所生成的数据,如 DataSet 或自定义报表业务对象。第二种机制是页输出缓存,它保存页处理输出,并在用户再次请求该页时,重用所保存的输出,而不是再次处理该页。

应用程序缓存

应用程序缓存提供了一种编程方式,可通过键/值对将任意数据存储在内存中。使用应用程序缓存与使用应用程序状态类似。但是,与应用程序状态不同的 是,应用程序缓存中的数据是易失的,即数据并不是在整个应用程序生命周期中都存储在内存中。使用应用程序缓存的优点是由 ASP.NET 管理缓存,它会在项过期、无效、或内存不足时移除缓存中的项。还可以配置应用程序缓存,以便在移除项时通知应用程序。有关更多信息,请参见缓存应用程序数据

使用应用程序缓存的模式是,确定在访问某一项时该项是否存在于缓存中,如果存在,则使用。如果该项不存在,则可以重新创建该项,然后将其放回缓存中。这一模式可确保缓存中始终有最新的数据。

有关更多信息,请参见如何:检索缓存项的值

页输出缓存

页输出缓存在内存中存储处理后的 ASP.NET 页的内容。这一机制允许 ASP.NET 向客户端发送页响应,而不必再次经过页处理生命周期。页输出缓存对于那些不经常更改,但需要大量处理才能创建的页特别有用。例如,如果创建大通信量的网页 来显示不需要频繁更新的数据,页输出缓存则可以极大地提高该页的性能。可以分别为每个页配置页缓存,也可以在 Web.config 文件中创建缓存配置文件。利用缓存配置文件,只定义一次缓存设置就可以在多个页中使用这些设置。

页输出缓存提供了两种页缓存模型:整页缓存和部分页缓存。整页缓存允许将页的全部内容保存在内存中,并用于完成客户端请求。部分页缓存允许缓存页的部分内容,其他部分则为动态内容。有关更多信息,请参见缓存 ASP.NET 页

部分页缓存可采用两种工作方式:控件缓存和缓存后替换。控件缓存有时也称为分段缓存,这种方式允许将信息包含在一个用户控件内,然后将该用户控件标 记为可缓存的,以此来缓存页输出的部分内容。这一方式可缓存页中的特定内容,并不缓存整个页,因此每次都需重新创建整个页。例如,如果要创建一个显示大量 动态内容(如股票信息)的页,其中有些部分为静态内容(如每周总结),这时可以将静态部分放在用户控件中,并允许缓存这些内容。

缓存后替换与控件缓存正好相反。这种方式缓存整个页,但页中的各段都是动态的。例如,如果要创建一个在规定时间段内为静态的页,则可以将整个页设置为进行缓存。如果向页添加一个显示用户名的 Label 控件,则对于每次页刷新和每个用户而言,Label 的内容都将保持不变,始终显示缓存该页之前请求该页的用户的姓名。但是,使用缓存后替换机制,可以将页配置为进行缓存,但将页的个别部分标记为不可缓存。在此情况下,可以向不可缓存部分添加 Label 控件,这样将为每个用户和每次页请求动态创建这些控件。有关更多信息,请参见缓存 ASP.NET 页的某些部分

根据请求参数缓存页

除缓存页的单一版本外,ASP.NET 页输出缓存还提供了一些功能,可以创建根据请求参数的不同而不同的页的多个版本。有关更多信息,请参见缓存页的多个版本

自动移除数据

出于以下原因之一,ASP.NET 可以从缓存中移除数据:

  • 由于服务器上的内存不足,开始一个称为“清理”的过程。
  • 由于缓存中的项已过期。
  • 由于项的依赖项发生了更改。

为了帮助管理缓存项,在将项从缓存中移除时,ASP.NET 会通知应用程序。

清理

清理是在内存不足时从缓存中删除项的过程。如果某些项在一段时间内未被访问,或是在添加到缓存中时被标记为低优先级,则这些项会被移除。ASP.NET 使用 CacheItemPriority 对象来确定要首先清理的项。有关更多信息,请参见如何:将项添加到缓存中

过期

除了清理外,在缓存项过期时,ASP.NET 会自动从缓存中移除这些项。向缓存添加项时,可以按下表中的描述设置其过期时间。

过期类型 说明
可调过期 指定某项自上次被访问后多长时间过期。例如,可以将某项设置为自上次在缓存中被访问后 20 分钟过期。
绝对过期 指定某项在设定的时间过期,而不考虑访问频率。例如,可以将某项设置为在 6:00 PM 过期,或四小时后过期。

依赖项

可以将缓存中某一项的生存期配置为依赖于其他应用程序元素,如某个文件或数据库。当缓存项依赖的元素更改时,ASP.NET 将从缓存中移除该项。例如,如果您的网站显示一份报告,该报告是应用程序通过 XML 文件创建的,您可以将该报告放置在缓存中,并将其配置为依赖于该 XML 文件。当 XML 文件更改时,ASP.NET 会从缓存中移除该报告。当代码请求该报告时,代码会先确定该报告是否在缓存中,如果不在,代码会重新创建该报告。因此,始终都有最新版本的报告可用。

ASP.NET 缓存支持下表中描述的依赖项。

依赖项 说明
键依赖项 应用程序缓存中的项存储在键/值对中。键依赖项允许项依赖于应用程序缓存中另一项的键。如果移除了原始项,则具有键依赖关系的项也会被移除。例如,可以添加一个名为 ReportsValid 的缓存项,然后缓存若干个依赖于 ReportsValid 键的报告。当 ReportsValid 项被移除时,所有依赖于它的缓存报告同样也会从缓存中移除。
文件依赖项 缓存中的项依赖于外部文件。如果该文件被修改或删除,则缓存项也会被移除。
SQL 依赖项 缓存中的项依赖于 Microsoft SQL Server 2005、SQL Server 2000 或 SQL Server 7.0 数据库中表的更改。对于 SQL Server 2005,缓存中的项可依赖于表中的某一行。有关更多信息,请参见使用 SqlCacheDependency 类在 ASP.NET 中缓存
聚合依赖项 通过使用 AggregateCacheDependency 类缓存中的项依赖于多个元素。如果任何依赖项发生更改,该项都会从缓存中移除。
自定义依赖项 可以用您自己的代码创建的依赖关系来配置缓存中的项。例如,可以创建一个自定义 Web 服务缓存依赖项,当调用 Web 服务得到一个特定值时,该依赖项就会从缓存中移除数据。

应用程序缓存项移除通知

当项从应用程序缓存中移除时,您可以收到通知。例如,如果有一个需要大量处理时间才能创建的项,当从缓存中移除该项时,您会收到通知以便可以立即替换该项。这样,下次请求该项时,用户便不必等待处理该项。有关更多信息,请参见如何:从缓存中移除项时通知应用程序

任务:

如何:使用文件依赖项缓存页输出

概念

ASP.NET 缓存中的新增功能
缓存 ASP.NET 页
缓存应用程序数据
使用 SqlCacheDependency 类在 ASP.NET 中缓存
FROM:MSDN