tomcat-session 共享

0.session的了解

在计算机中，尤其是在网络应用中，称为“会话控制”。Session 对象存储特定用户会话所需的属性及配置信息。这样，当用户在应用程序的 Web 页之间跳转时，存储在 Session 对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。当用户请求来自应用程序的 Web 页时，如果该用户还没有会话，则 Web 服务器将自动创建一个 Session 对象。当会话过期或被放弃后，服务器将终止该会话

一. 在集群系统下实现session统一的有如下几种方案:

1、请求精确定位：session sticky，

例如nginx基于访问ip的hash策略，即当前用户的请求都集中定位到一台服务器中，这样单台服务器保存了用户的session登录信息，如果宕机，则等同于单点部署，会丢失，会话不复制

2.session复制共享：session replication

tomcat自带session共享，主要是指集群环境下，多台应用服务器之间同步session，使session保持一致，对外透明。 如果其中一台服务器发生故障，根据负载均衡的原理，调度器会遍历寻找可用节点，分发请求，由于session已同步，故能保证用户的session信息不会丢失，会话复制.

不足之处：

1）必须在同一种中间件之间完成（比如tomcat-tomcat之间），

2）session复制带来的性能损失会快速增加，特别是当session中保存了较大的对象,而且对象变化较快时, 性能下降更加显著，会消耗系统性能。这种特性使得web应用的水平扩展受到了限制。

3）Session内容通过广播同步给成员，会造成网络流量瓶颈，即便是内网瓶颈

4）在大并发下表现并不好

3.基于 memcache/redis缓存的 session 共享

用cacheDB存取session信息，应用服务器接受新请求将session信息保存在cache DB中，当应用服务器发生故障时，调度器会遍历寻找可用节点，分发请求，当应用服务器发现session不在本机内存时，则去cacheDB中查找，如果找到则复制到本机，这样实现session共享和高可用

二.实验环境：

nginx  ---->后面有两个tomcat（一台服务器两个tomcat）

此处ngixn安装，jdk tomcat安装省略。

0.tomcat的访问地址：

tomcat   192.168.9.174:8080

tomcat2:  192.168.9.174:8081  ---->修改8005,8009,8080的端口

1.编写脚本查看sessionid

A.mkdir /usr/local/{tomcat,tomcat2}/webapps/demo

vim index.jps

C.重新启动tomcat  :   /usr/local/tomcat/bin/shutdown.sh &&  /usr/local/tomcat/bin/startup.sh

D.查看效果(只有sessionID是不同的，还有来自那台服务器的返回)：

2.配置session共享：

A.修改配置文件：  server.xml

在Server.xml中，找到被注释<Cluster/>节点，在下面添加如下内容

B.修改web.xml文件：

添加标签<distributable / >

mkdir /usr/local/{tomcat,tomcat2}/webapps/demo/WEB-INF

cp /usr/local/tomcat/ROOT/web.xml   /usr/local/{tomcat,tomcat2)/webapps/demo/WEB-INF

D.重新启动tomcat：

  /usr/local/tomcat/bin/shutdown.sh &&  /usr/local/tomcat/bin/startup.sh

E.查看端口监听状态：

F：关闭防火墙和selinux

/etc/init.d/iptables stop  &&setenforce 0 

3.配置nginx：

A.修改配置文件：

B：修改防火墙端口8002

-A INPUT -m state --state NEW -m tcp -p tcp --dport 8002 -j ACCEPT

/etc/init.d/iptables restart 

C.重新启动nginx：

/usr/local/nginx/sbin/nginx -s reload

4.测试：

注意：

目前此实验只成功于一台服务器多个tomcat并且访问的项目名一致。

Haproxy有8种负载均衡算法（balance），分别如下：

1.balanceroundrobin# 轮询，软负载均衡基本都具备这种算法

2.balancestatic-rr# 根据权重，建议使用

3.balanceleastconn# 最少连接者先处理，建议使用

4.balancesource# 根据请求源IP，建议使用

5.balanceuri# 根据请求的URI

6.balanceurl_param，#根据请求的URl参数'balanceurl_param'requiresanURLparametername

7.balancehdr(name)# 根据HTTP请求头来锁定每一次HTTP请求

8.balancerdp-cookie(name)# 根据据cookie(name)来锁定并哈希每一次TCP请求

由于负载请求分发到不同服务器，可能导致Session会话不同步的问题，若想实现会话共享或保持，可采用如下3种方式：

1.用户IP 识别

haroxy 将用户IP经过hash计算后 指定到固定的真实服务器上（类似于nginx 的IP hash 指令）

配置指令

balance source

2.Cookie 识别

haproxy 将WEB服务端发送给客户端的cookie中插入(或添加加前缀)haproxy定义的后端的服务器COOKIE ID。

配置指令例举

cookie SESSION_COOKIE insert indirect nocache

用firebug可以观察到用户的请求头的cookie里 有类似” Cookie jsessionid=0bc588656ca05ecf7588c65f9be214f5SESSION_COOKIE=app1” SESSION_COOKIE=app1就是haproxy添加的内容

3.Session 识别

haproxy 将后端服务器产生的session和后端服务器标识存在haproxy中的一张表里。客户端请求时先查询这张表。

配置指令例举

appsession JSESSIONID len 64 timeout 5h request-learn

---