nginx 负载均衡、用数据库存储Session,来实现多站点共享Session[转]

多站点共享Session常见的作法有:

1、使用.net自动的状态服务(Asp.net State Service);

2、使用.net的Session数据库

3、使用Memcached。

4、使用Cookie方式实现多个站点间的共享(这种方式只限于几个站点都在同一域名的情况下);

这里我们就 演练一下 以数据库的形来存储Session,来实现多站点共享Session。

首先我们 建好一下站点,如下图:

Default.aspx

其中 有二个Button  ,SetSession 主要是用于给一个 Session 赋值(如:Session["ShareValue"] = “abcd”

) ,

GetSession 主要就是获得 一个 Session 值。

具体代码如下:

代码部分就这么多就行了…

下面就是要配置一下 Web.config了 , 其实主要就是在 <system.web>

 这个节点中 增加 machineKey 及 sessionState 这两个节点,

1.增加machineKey 主要作用是:

“按照MSDN的标准说法:“对密钥进行配置,以便将其用于对 Forms 身份验证 Cookie 数据和视图状态数据进行加密和解密,并将其用于对进程外会话状态标识进行验证。”也就是说Asp.Net的很多加密,都是依赖于machineKey里面的值,例如Forms 身份验证 Cookie、ViewState的加密。默认情况下,Asp.Net的配置是自己动态生成,如果单台服务器当然没问题,但是如果多台服务器负载均衡,machineKey还采用动态生成的方式,每台服务器上的machinekey值不一致,就导致加密出来的结果也不一致,不能共享验证和ViewState,所以对于多台服务器负载均衡的情况,一定要在每台站点配置相同的machineKey。“ ,具体可以查一下其它资料。

2.增加 sessionState 主要是让 Session 保存在数据库中。

具体配置如下:

<machineKey validationKey="86B6275BA31D3D713E41388692FCA68F7D20269411345AA1C17A7386DACC9C46E7CE5F97F556F3CF0A07159659E2706B77731779D2DA4B53BC47BFFD4FD48A54"

decryptionKey="9421E53E196BB56DB11B9C25197A2AD470638EFBC604AC74CD29DBBCF79D6046"

validation="SHA1" decryption="AES"/>

<sessionState mode="SQLServer" sqlConnectionString="Data Source=PC-07195;Initial Catalog=AWBUISession;Persist Security Info=True;User ID=jins;[email protected]#$1234" allowCustomSqlDatabase="true" cookieless="false" timeout="100"/>

网站部分 这样就好了。。。 下面就是要配置据库了…..

数据库配置:

使用aspnet_regsql.exe工具

ASP.NET 2.0版本后微软提供了aspnet_regsql.exe工具可以方便的配置Session数据库.该工具位于 Web 服务器上的"系统根目录\Microsoft.NET\Framework\版本号"文件夹中.

使用举例:

aspnet_regsql.exe -S . -U sa -P 123456 -ssadd -sstype p

-S参数:

表示数据库实例名称. 可以用"."表示本机.

-U和-P参数:

表示用户名和密码.

-E参数:

可以再-U –P 与 -E中选择一组. –E表示以当前系统用户通过windows身份验证登录数据库, -U -P则是使用SqlServer用户登录数据库.

-ssadd / –ssremove 参数:

-ssadd表示是添加Session数据库, -ssremove表示移除Session数据库.

sstype 参数说明:

t 将会话数据存储到 sql server tempdb 数据库中。这是默认设置。如果将会话数据存储到 tempdb 数据库中,则在重新启动 SQL Server 时将丢失会话数据。
p 将会话数据存储到 ASPState 数据库中,而不是存储到 tempdb 数据库中。
c 将会话数据存储到自定义数据库中。如果指定 c 选项,则还必须使用 -d 选项包括自定义数据库的名称。

我的设置是:aspnet_regsql.exe -S . - E -d AWBUISession -ssadd -sstype c

好了。基本的 我们就已经搞定了。。

现在 我们分别把我们刚建的一个网站 部署 到 IIS 中。不过我们既然要负载。至少也的部署两份。

我们把 其中一个 服务器中的 defaut.aspx 中 “服务器 1” 改成 “服务器 2” ,这样做的主要目地是 做一下 区别!

具体如下:

两个网站的 URL分别是:

server 1:127.0.0.1:8081;

server 2:127.0.0.1:8080;

OK。下面我们就是 配置 Nignx了。

首先 在 nginx\conf 配置  文件中找到 nginx.conf 这个文件 ,就记事本打开,

做如上的 设置:

OK。  nginx  这样配置 就算OK 了。 我们启动一下 nginx ..

在浏览器中 输入我们 在 nginx 中配置的 URL 如:127.0.0.1:8090

我们会看到 服务器 1 已经开始为我们服务了,我们再点一下 “SetSession”来设置一下一个 会话值,

我们会看到 服务器 2 开始 工作。这时我们再点一下 “GetSesion”看一下 刚才在 服务器 1 设置 的会话值,结果如下 :

出现这种情况 ,主要就是在数据库中存储 一个会话时 没有做到 服务器1 和服务2的Session 共享,主要是 在

ASPStateTempSessions 这个表中的 一个SessionID ,

其中的SessionId包括两个部分:网站生成的24位SessionID及8位AppName对于不同的站点,其AppName不同,在能够在不同站点下使24位SessionID相同的情况下,要保证经过组合加上AppName后的SessionID相同,可以通过修改存储过程TempGetAppID,使其得到的SessionID与AppName无关,修改TempGetAppID如下:

ALTER PROCEDURE [dbo].[TempGetAppID]

@appName    tAppName,

@appId      int OUTPUT

AS

SET @appName = ‘Test‘ --LOWER(@appName) 修改这里,使多个站点的APPname ,为一个固定值。

SET @appId = NULL

SELECT @appId = AppId

FROM [AWBUISession].dbo.ASPStateTempApplications

WHERE AppName = @appName

IF @appId IS NULL BEGIN

BEGIN TRAN

SELECT @appId = AppId

FROM [AWBUISession].dbo.ASPStateTempApplications WITH (TABLOCKX)

WHERE AppName = @appName

IF @appId IS NULL

BEGIN

EXEC GetHashCode @appName, @appId OUTPUT

INSERT [AWBUISession].dbo.ASPStateTempApplications

VALUES

(@appId, @appName)

IF @@ERROR = 2627

BEGIN

DECLARE @dupApp tAppName

SELECT @dupApp = RTRIM(AppName)

FROM [AWBUISession].dbo.ASPStateTempApplications

WHERE AppId = @appId

RAISERROR(‘SQL session state fatal error: hash-code collision between applications ‘‘%s‘‘ and ‘‘%s‘‘. Please rename the 1st application to resolve the problem.‘,

18, 1, @appName, @dupApp)

END

END

COMMIT

END

RETURN 0

经过以上修改之后,下面要实现多个站点共用同一个SessionID.

重启一下各站点。再在浏览一下网站

点 “SetSession”,

再点:“GetSession”

这样 我们就看到 服务器2 给出了我们 刚才在 服务器 1 中设置 的会话值了。

我们 再点:“GetSession”,

可以看到  服务器1 和服务器 2 返回的是相同的结果,达到了 “多站点共享Session”

附加一点: Session 过期删除,主要是 在 SQL server 代理中的  作业完成。

具体的可以,查一下其它相关资料.

时间: 2024-10-11 07:14:24

nginx 负载均衡、用数据库存储Session,来实现多站点共享Session[转]的相关文章

nginx负载均衡集群中的session共享说明

在网站使用nginx+php做负载均衡情况下,同一个IP访问同一个页面会被分配到不同的服务器上,如果session不同步的话,就会出现很多问题,比如说最常见的登录状态. 下面罗列几种nginx负载均衡中session同步的方式 1)不使用session,换用cookiesession是存放在服务器端的,cookie是存放在客户端的,我们可以把用户访问页面产生的session放到cookie里面,就是以cookie为中转站.你访问web服务器A,产生了session然后把它放到cookie里面,当

nginx负载均衡 - session失效

最近迷上了Nginx,真实麻雀虽小,五脏俱全..功能实在强大.. nginx不单可以作为强大的web服务器,也可以作为一个反向代理服务器,而且nginx还可以按照调度规则实现动态.静态页面的分离,可以按照轮询.ip哈希.URL哈希.权重等多种方式对后端服务器做负载均衡,同时还支持后端服务器的健康检查. 如果只有一台服务器时,这个服务器挂了,那么对于网站来说是个灾难.因此,这时候的负载均衡就会大显身手了,它会自动剔除挂掉的服务器. 下面简单的介绍下我使用Nginx做负载的体会 下载---安装Ngi

nginx负载均衡算法

nginx负载均衡设置 模块官方介绍: http://wiki.nginx.org/HttpUpstreamModule 说说upstream里的server指令: server 后面可以是域名格式,也可以是socket格式[ip:port],后面还可以带参数. 参数有下面几个:       weight = NUMBER - 设置服务器的权重值,默认为1. 值越大,分配的请求越多.只适用于轮询这种LB策略.       max_fails = NUMBER - 在fail_timeout设置的

linux下nginx负载均衡部署

nginx负载均衡部署 Nginx("engine x") 是一个高性能的 HTTP 和 反向代理 服务器,也是一个 IMAP/POP3/SMTP 代理服务器. Nginx 是由 IgorSysoev 为俄罗斯访问量第二的 Rambler.ru站点开发的,第一个公开版本0.1.0发布于2004年10月4日.其将源代码以类BSD许可证的形式发布,因它的稳定性.丰富的功能集.示例配置文件和低系统资源的消耗而闻名.2011年6月1日,nginx 1.0.4发布. 一般我们都需要先装pcre,

lvs、haproxy、nginx 负载均衡的比较分析

lvs.haproxy.nginx 负载均衡的比较分析 对软件实现负载均衡的几个软件,小D详细看了一下,从性能和稳定上还是LVS最牛,基本达到了F5硬件设备的60%性能,其他几个10%都有点困难. 不过就因为LVS忒牛了,配置也最麻烦了,而且健康检测需要另外配置Ldirector,其他HAPROXY和NGINX自己就用,而且配置超级简单. 所以小D建议,如果网站访问量不是门户级别的用HAPROXY或者NGINX就OK了,到了门户级别在用LVS+Idirector吧 哈哈 lvs和nginx都可以

Nginx 负载均衡-加权轮询策略剖析

本文介绍的是客户端请求在多个后端服务器之间的均衡,注意与客户端请求在多个nginx进程之间的均衡相区别(Nginx根据每个工作进程的当前压力调整它们获取监听套接口的几率,那些当前比较空闲的工作进程有更多机会获取到监听套接口,从而客户端的请求到达后也就相应地被它捕获并处理).如果Nginx是以反向代理的形式配置运行,那么对请求的实际处理需要转发到后端服务器运行,如果后端服务器有多台,如何选择一台合适的后端服务器来处理当前请求,就是本文要说的负载均衡.这两种均衡互不冲突并且能同时生效. nginx不

Nginx负载均衡及反向代理

Nginx 负载均衡 什么是nginx负载均衡? Nginx作为一个强大的web服务器管理软件,自身带有负载均衡和反向代理的功能,那么他和lvs之间有什么区别呢? LVS负载:是基于4层的负载均衡, 优点: 1抗负载能力强 2配置性低 3工作稳定 4无流量 5基本支持所有应用负载均衡,如WEB,数据库 Nginx负载:基于7层的负载均衡 特点: 1nginx工作在网络7层,他可以针对http本身做分发策略,如域名,目录结构等 2nginx对网络依赖小 3配置简单,测试方便 4nginx同样能承受

Nginx负载均衡组件模块

Nginx负载均衡组件模块 实现Nginx负载均衡的组件主要有两个: n  ngx_http_proxy_module proxy代理模块,用于把请求后抛给服务器节点或upstream服务器池 n  ngx_http_upstream_module 负载均衡模块,可以实现网站的负载均衡功能及节点的健康检查 1.upstream模块 upstream模块允许Nginx定义一组或多组节点服务器组,使用时可以通过proxy_pass代理方式把网站的请求发送到事先定义好的对应upstream组的名字上,

nginx - 负载均衡的意义

nginx负载均衡是根据它的均衡策略,将负载(请求)分配给后端不同的服务器处理.如后端某些服务器挂了,会分配给其他运行正常的服务器处理,如某些服务器正在处理,新一次的请求会让那些比较空闲的服务器处理. 所以它能使你的服务响应快,可用性高. 均衡策略: 1.轮询(默认) 每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除. 2.weight 指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的情况. 2.ip_hash 每个请求按访问ip的hash结