外文翻译--在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变量毕