一般来说，我们在java中都通过如下代码进行用户登录后的服务端注册，并且在用户下次请求时无需再登陆一遍，这就是Servlet的Session。使用了这种Session策略，那么Web容器比如tomcat就为当前用户生成一个SessionID，并且以这个SessionID为索引，存储这个用户相关的键值对，比如用户名，登陆时间一类的。存储在服务器的内存中。同时再response里向用户浏览器中设置一个cookie，这个cookie的名字为jsessionid，内容为服务器生成的随机数SessionID。在用户第二次请求时，将这个cookie发给服务器，服务器根据这个SessionID到内存中寻找相关数据，把用户名什么的提取出来，服务器就可以在本来无状态的HTTP连接中识别出这是哪个客户发出的请求，然后绘制相关页面。
这中Session机制使用简单方便，被使用了很长时间。但是一旦做成集群，这种方式就不灵了。以NGINX默认的轮询方式为例，用户在A服务器上登陆成功，SessionID和用户名等相关信息写入了A服务器的内存中，该用户第二次请求时被NGINX分发到了B服务器，而B服务器没用该用户的SessionID和用户名等相关信息，于是要求用户再登陆一遍。用户第二次登陆之后发送第三次请求，被NGINX分配到了A或者C服务器，于是用户又必须登陆一遍，总之这个用户一直没法登陆成功。
基于以上现象，有几种存储session 的方法，如下：
1. 数据库存储session
2.使用 memcached，redis等存储session
3. 使用nginx 内置模块，ip_hash
4. 使用cookie的HASH来区分同一个用户的不同链接
前面我们已经知道了如果使用Servlet Session的话，Web容器会自动的在用户浏览器上建立名为jsessionid的cookie，并且值就是服务器端的SessionID。另一方面，新版的NGINX不光可以通过IP的hash来分发流量，也可以通过url的hash，cookie的hash，header的hash等等进行链接的固定分配。由于用户登陆成功以后名为jsessionid的cookie就有了一个短期固定的值，而且每个用户都不一样，那么我们就可以根据这个sessionid的hash值为它分配一个服务器。在当前sessionID起作用的时候那么分配的服务器也是同一个，并且不需要安装第三方的插件。
本次使用第4种方法，使用cookie 是用户分配的服务器是同一个。nginx 配置如下：
[root@www vhosts]# cat load.conf
upstream tomcat_server {
hash $cookie_jsessionid;
# hash $request_uri;
server 172.16.31.16:8080;
server 172.16.31.17:8080;
}
#error_page配置备份：
upstream backup {
server 11.11.11.14:80; }
error_page 404 500 502 503 504 =200 @fetch; #注意：=200里的等号，左边有空格，右边没空格
server {
listen 80;
server_name www.load.com;
root /data/wwwroot/www.load.com;
index index.html index.htm index.php;
access_log /usr/local/nginx/logs/www.load.com-access.log gufan;
error_log /usr/local/nginx/logs/www.load.com-error.log;
location /stat {
proxy_pass
http://tomcat_server;
proxy_set_header
Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_intercept_errors on;
proxy_next_upstream off;
}
location @fetch {
proxy_pass http://backup;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}