（毕业学术论文设计）-外文翻译--在SQLServer数据库里存储Session.docVIP

PAGE PAGE 9 在SQL Server数据库里存储Session HTTP是个状态很不确定的协议，为了允许用户通过请求保存状态信息，ASP.NET提供了Session存储机制。这些Session变量按每个用户被存储起来。在传统的ASP里，你只能在Web服务器的内存里暂时存储Session变量，但是这个方法已经被证明了在扩展性和可依赖性上的不足。在ASP.NET里，你可以为你的每个请求定制Session状态存储。本文将探讨存储Session变量可伸缩性和可靠性都很好的方式之一的SQL Server 。 在传统的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变量？毕竟，它们存储在和S2完全没有任何关联的Web服务器S1的内存中。这意味着R2仍然得等待S1的空闲。这种事情很显然是Web服务器群资源的浪费。 ASP.NET 2.0及其Session信息存储 ASP.NET 2.0允许你存储session变量在三个不同地方: （1）在网站服务器的内存中存储(进程中的)。 （2）在一台专门用来存放Session变量的服务器中存储。( Session状态信息存储服务器 ) （3）在一个SQL Server的数据库里面存储。 默认情况是第一种存储模式。 模式二和模式三通常被称为“进程外”的模式，因为Session变量的存储和Web站点没有关系。 在这篇文章，你将被限制在只探索第三种模式。在SQL Server数据库里存储Session变量具有以下优点: （1）可扩展性: 如果您正在找一个高度可扩展性的方法来储存Session变量 ，SQL Server正是如此，它比其它的可扩展性更好。 Web服务器群可以很容易地获取Session变量，因为它们都储存在一个独立的数据库。 （2）可靠性:因为数据是很真实的存放在数据库里面，它比其他方法都要好。不用去担心服务器重启的问题。 （3）安全: SQL Server比在内存或Session状态信息存储服务器中更安全。 你可以更简单的通过配置SQL Server的安全选项来保护你的数据。 在web.config 文件里，可以通过定义一个session State来配置Session状态模式 。 备注: 如果是在Web服务器群里， Web服务器群的每一台服务器的IIS METABASE的应用程序路径应该是完全相同的。Session结束事件不会因为任何进程之外的模式发生。 配置SQL Server来储存Session状态 在你真正的在SQL Server存储Session状态之前， 你需要先配置它。 配置工作都是通过一个名为aspnet_regsql.exe的命令行工具来完成的。 在SQL Server里面，你可以在三个可能的地点存储Session状态， (1)临时存储: 在这种情况下，Session状态保存在SQL Server的tempdb 数据库里面。 该工具建立一个数据库名为asp