外文翻译--在SQL Server数据库里存储Session.doc
1在SQLSERVER数据库里存储SESSIONHTTP是个状态很不确定的协议,为了允许用户通过请求保存状态信息,ASPNET提供了SESSION存储机制。这些SESSION变量按每个用户被存储起来。在传统的ASP里,你只能在WEB服务器的内存里暂时存储SESSION变量,但是这个方法已经被证明了在扩展性和可依赖性上的不足。在ASPNET里,你可以为你的每个请求定制SESSION状态存储。本文将探讨存储SESSION变量可伸缩性和可靠性都很好的方式之一的SQLSERVER。在传统的ASP里,默认的SESSION状态保存在服务器的内存中。但是,这种做法带来两方面的问题(1)它让服务器超负荷,影响了网站服务器的伸缩性能。(2)它不能有效地应用于WEB服务器群。让我在一些细节上讨论这些问题,使你能为你选择了SESSION存储感到庆幸。SESSION变量依据每个用户为基础生成。默认情况下,它们都保留在WEB服务器的内存中。想象一个有着成千上万用户的网站。由于巨大的用户数量,WEB服务器存储的活跃SESSION的数目也将非常的多。这意味着你存放着非常多的SESSION数据在WEB服务器的内存中。如果不断的对服务器增加负载,它可能达到饱和,以至造成对应用程序整体扩展性能上的不良影响。为了解决这个影响到扩展性能的问题,实现WEB集群。所谓的WEB集群是一组网络服务器并行运行,服务器集群里的每个WEB服务器都有您的网站的一个镜像。您的网站的流通负载平均分配给每个可用的服务器,从而达到负载平衡。在WEB服务器的内存里存储SESSION变量会阻碍WEB集群的建立,下面将举例来说明假定有三个WEB服务器S1,S2,和S3。并行地连接在一起接受用户请求。假定这个时候有一个请求R1来到服务器集群并且负载平衡逻辑判定S2,S3都因为某些其他的任务而没有空闲,但是S1可以处理这个请求。很显然,这个请求会被送到S1进行处理。现在,想象在这个处理过程当中你在S1的内存中存储了某个SESSION变量。到目前为止,一切还很好。过了一些时间,同样的用户有了另一个请求R2,这个请求需要上一个请求所存储的SESSION变量。但是这个时候S1已经被一些任务使用着,而S2,S3却处于空闲的状态。你可以猜到根据每一条的负载平衡规则,R2将会被送到S2进行处理。但是,如果那发生了,S2怎么能够得到SESSION变量毕