负载均衡服务器session共享的解决方案

在ASP.NET的程序中要使用Session对象时，必须确保页面的@page指令中EnableSessionState属性是True或者Readonly，并且在web.config文件中正确的设置了SessionState属性。

　　ASP.NET中Session的状态保持是由web.config文件中的标记下的标记的mode属性来决定的。该属性有四种可能的值：Off、Inproc、StateServer和SQlServer。

　　设为Off会禁用Session。

　　Inproc是缺省的设置,这种模式和以前的ASP的会话状态的方法是类似的,会话的状态会被保存在ASP.NET进程中，它的优点是显而易见的：性能。进程内的数据访问自然会比夸进程的访问快。然而，这种方法Session的状态依赖于ASP.NET进程，当IIS进程崩溃或者正常重起启时，保存在进程中的状态将丢失。

　　为了克服Inproc模式的缺点，ASP.NET提供了两种进程外保持会话状态的方法。

　　ASP.NET首先提供了提供了一个Windows服务：ASPState,这个服务启动后，ASP.NET应用程序可以将mode属性设置为“SateServer”,来使用这个Windows服务提供的状态管理方法。

　　除了在web.config文件中设置mode属性为StateServer外，还必须设置运行StateServer服务器的IP地址和端口号.

1、如果在IIS所在的机器运行StateServer则IP地址就是127.0.0.1,端口号通常是42424.配置如下：

　　mode=”StateServer”

　　stateConnectionString="tcpip=127.0.0.1:42424"

2、找一台服务器作为Session服务器（如IP为：192.168.1.244），启动其Windows中的ASP.NET State Service（默认的端口号为42424），把启动类型改为自动；
3、 修改Session服务器注册表中的项HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services \aspnet_state\Parameters中的AllowRemoteConnection 键的值为1，其中的Port键控制ASP.NET State Service的监听端口；修改后需要重启ASP.NET State Service才生效；

4、每台服务器的web。config 的　　stateConnectionString都指向这台服务器

　　使用这种模式,会话状态的存储将不依赖IIS进程的失败或者重启,会话的状态将存储在StateServer进程的内存空间中。

　　另一种会话状态模式是SQLServer模式。这种模式是将会话的状态保存在SQL Server数据库中的。使用这种模式前，必须至少有一台SQL Server服务器，并在服务器中建立需要的表和存储过程。.NET SDK提供了两个脚本来简化这个工作：InstallSqlState.sql和UnInstallSqlState.sql。这两国文件存放在下面路径中：

　　WinntMicrosoft.NETFramework

　　要配置SQL Server服务器，可以在命令行中运行SQL Server提供的命令行工具osql.exe

　　osql -s [server name] -u [user] -p [password]

　　例如：

　　osql -s (local) -u as -p “”-i InstallSqlState.sql

　　做好必要的数据库准备工作后，将web.config文件中的sessionstate元素的mode属性改为”sqlserver”,并指定SQL连接字符串。具体如下：

　　mode="SQLServer"

　　sqlConnectionString="data source=127.0.0.1;userid=sa;password=;Trusted_Connection=yes"

　　使用SQLServer模式处了可以使Session的状态不依赖于IIS服务器之外，还可以利用SQL Server的集群，使状态存储不依赖于单个的SQL Server,这样就可以为应用程序提供极大的可靠性。

 

分类: IIS, 负载均衡

标签: 服务器, 负载均衡, session共享

关于ASP.NET中的负载均衡

ASP.NET站点中做负载均衡：

基于HTTP协议我们可能发现我们要解决两点问题：

第一，做到负载均衡，我们需要一个负载均衡器。

可以通过DNS轮询来做，在DNS服务器上配置为每次对我们做负载均衡的同一主机名的DNS查询得到不同的IP地址。这样的好处是配置简单投入较小，缺点是浏览器访问各个服务器的机会是均等的，不能根据服务器的负载程度自动把请求路由到负载较小的服务器。

可以通过专用的负载均衡设备，通过监测后台数台服务器的负载情况，自动把HTTP请求转发到负载较轻的服务器。另外必须监测后台服务器的IIS负载情况，而不是整台服务器的CPU负载。同时可能需要在负载均衡器和后台服务应用之间建立心跳连接，以避免出现某台服务器IIS进程或者其中跑的应用已经down掉，负载均衡器反而监测到这台服务器的负载最小而把大量请求转发的这台服务器，达到相反的效果。

第二，Session状态的保持和迁移。

    由于HTTP协议的无状态性，我们一般是在Session中保存客户端的一些状态数据，负载均衡之后，前后两次HTTP请求所到达的服务器可能不是同一台，这就造成可能出现这样的情况，前一此请求处理中设置的session在第二次请求中变得不可用了，造成应用程序出错。所以我们要把session跟随迁移。实现的方法就是session的统一存储和服务器间共享。

    在ASP.NET中服务器保存session有五种方式，Off不说了，InProc是保存在服务器进程的内存中，显然不能满足要求。另外两种能够满足：

StateServer是把session保存在专门的状态服务器中。这样各台服务器都存取同一个StateServer，达到共享的目的。

SQLServer是把session保存在数据库中。同样能达到目的。

Custom自定制的存储方案，我们自己写当然能够实现。

比较一下，Custom这种自己实现比较麻烦一般不用，SQLServer可以利用数据库的cluster达到高性能和高可用性的目的，StateServer当然也可以通过手段达到高可用性，不过似乎不能实现集群所以性能也有所限制。

另外如果要做负载均衡在StateServer和SQLServer中配置session时，必须在web.config中重写machineKey节点：

        <machineKey 

          validationKey="1234567890123456789012345678901234567890AAAAAAAAAA"

          decryptionKey="123456789012345678901234567890123456789012345678"

          validation="SHA1"

          decryption="Auto"

        />

否则各个应用服务器拿到的session还是不一样的。

可能Custom方式可以自己定义存取session方式忽略machineKey，这可能就不必要了，因为没有做过，不多说。