十四、Nginx负载均衡压测Session问题

一、Nginx负载均衡压测Session问题

什么是session问题

用户A登陆访问nginx，分配到tomcat1，程序员可以把用户信息放到tomcat1的缓存session（tomcat自带的session缓存）中，这样方便用户以后操作哦，不需要访问数据库

但当用户A下订单操作访问nginx，如果分配到tomcat2，他的用户信息如果还是从当前服务器缓存session获取，这时候服务器是tomcat2，如果没有额外支持（就是其他tomcat没有把session共享出来），就会出现session问题。session问题会影响nginx轮询、最少连接数、负载均衡权重这三个策略的执行

针对session问题对负载均衡策略的影响，可以考虑使用IP地址哈希的负载均衡策略方法和URL哈希策略方法

IP地址哈希的负载均衡策略方法：是将一个IP地址发送的请求放在同一个tomcat服务器中，用来解决session问题

URL哈希策略方法：是根据地址去分配请求，用来解决session问题

二、IP地址哈希介绍

前述的两种负载均衡方案中，同一客户端连续的Web请求可能会被分发到不同的后端服务器进行处理，

因此如果涉及到会话Session，那么会话会比较复杂。常见的是基于数据库的会话持久化。

要克服上面的难题，可以使用基于IP地址哈希的负载均衡方案。

这样的话，同一客户端连续的Web请求都会被分发到同一服务器进行处理，即同一个ip地址发出来的请求，nginx会分发到同一个tomcat进行处理，以此来解决session问题。

配置的例子如下：

http{

    upstream sampleapp {

        ip_hash;

        server <<dns entry or IP Address(optional with port)>>;

        server <<another dns entry or IP Address(optional with port)>>;

    }

    ....

    server{

       listen 80;

       ...

       location / {

          proxy_pass http://sampleapp;

       }

    }

上面的例子只是在upstream节添加了ip_hash配置。其它的配置同轮询配置。

三、url_hash（第三方）哈希介绍

按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。

upstream backserver {

server squid1:3128;

server squid2:3128;

hash $request_uri;

hash_method crc32;

}

在需要使用负载均衡的server中增加

proxy_pass http://backserver/;

upstream backserver{

ip_hash;

server 127.0.0.1:9090 down; (down 表示单前的server暂时不参与负载)

server 127.0.0.1:8080 weight=2; (weight 默认为1.weight越大，负载的权重就越大)

server 127.0.0.1:6060;

server 127.0.0.1:7070 backup; (其它所有的非backup机器down或者忙的时候，请求backup机器)

}

max_fails ：允许请求失败的次数默认为1.当超过最大次数时，返回proxy_next_upstream 模块定义的错误

fail_timeout:max_fails次失败后，暂停的时间

四、实际环境下解决Session问题的方法

方案1： 开发不把共享信息放到session（session不放置数据），这样就不会在nginx分发请求时由于session问题而导致服务处理失败

方案2： 用全局缓存，比如用redis缓存，这样所有tomcat信息可以共享，就是将所有的session信息都存放在redis中，redis的读写速度快，又可以做缓存，需要进行配置，配置连接到redis

 http://www.cnblogs.com/interdrp/p/4056525.html

 

前面两种要开发改造程序  大量修改业务代码

3 基于ip分配 ip_hash; (简单粗暴，但是有缺陷就是分配不均，不能很好地实现nginx负载均衡，举例：比如一个公司进行访问，可能这个公司有100多台机器访问，但是他们对外的地址就只有一个，如果使用ip_hash的方法，就会导致服务端一个tomcat使劲处理这个公司100多台机器发送的请求，而服务端其他机器不进行处理，导致请求分配不均)

4 基于浏览器 cookie的 sticky （如果cookie关闭，app接口就无法支持了）

http://www.ttlsa.com/nginx/nginx-modules-nginx-sticky-module/

5 改造底层tomcat session：相当于开发不用修改代码，只是将session放置的信息再放置到redis缓存服务器中，这样也可以解决session问题，即使前后多个请求不在同一个tomcat服务器中，也可以通过redis缓存服务器去获取想要得到的信息