除去那些对容器依赖特别高的方案(如: 基于Tomcat的memcached-session-manager / tomcat-redis-session-manager,基于Jetty的jetty-nosql-memcache / jetty-session-redis ),自己整理了下分布式/集群下的session共享方案,以备不时之需。
1、F5 BIG-IP 硬件实现session粘性复制
F5 硬件,可以作为HTTP负载均衡器使用,可以将用户IP与Session通过F5进行的绑定,使其Session保持一致性。是直接通过智能交换机实现负载,与系统无关。了解不多,简单说就这么多。
2、Nginx 的ip_hash特性对访问IP和服务器进行绑定
当某个ip下的客户端请求指定(固定,因为根据IP地址计算出一个hash值,根据hash值来判断分配给那台服务器,从而每次该ip请求都分配到指定的服务器)的服务器,这样就可以保证有状态请求的状态的完整性,不至于出现状态丢失的情况。缺点: ip_hash方案必须保证Nginx是最前端的服务器(接受真实的ip),如果nginx不是最前端的服务器,还存在中间件(中间服务器什么的),那么nginx获取的ip地址就不是真实的ip地址,那么这个ip_hash就没有任何意义。
3、将session保存到nosql数据库中(推荐)
这个方案有很多种方式:1、 使用框架的会话管理工具spring-session ;2、 使用shiro这种自带session(非httpsession)的权限框架 。
可以存到redis 或者 memcache 中。
先说第一种,它替换了Servlet那一套会话管理,既不依赖容器,又不需要改动代码,并且是用了spring-data-redis那一套连接池,可以说是最完美的解决方案。
第二种前提你的项目中用到了shiro, 需要重写shiro的SessionDao将session存入redis来实现session共享,可以自己重写或者找现成的(shiro-redis)。
4、使用Cookie共享session
Java Web的共用的用户鉴权机制是采用Session-Cookie技术,实现原理是:用户登录时,请求到达服务器,服务器调用通过getSession()方法判断session是否存在,如果不存在,则新建session,并通过其算法为session生成一个随机数作为sessionId,开发者可在session中储存一些用户信息;第二次请求时,如获取用户信息,getSession()方法判断session存在,则取出session,而不是新建,从而从session中获取到用户的相关信息。
客户端请求时,可以将cookie信息储存于request的head中发送给服务器;
服务器响应时,可以将cookie信息置于response中回传给客户端。
此方案可以说是独辟蹊径了,将分布式思想用到了极致。如上文分析所说,session-cookie机制中,session与cookie相互关联,以cookie做中转站,用来找到对应的session,其中session存放在服务器。那么如果将session中的内容存放在cookie中呢,那么则省略了服务器保存session的过程,后台只需要根据cookie中约定的标识进行鉴权校验即可。
此法, 受http协议头长度限制,cookie中存储的信息不宜过多 ,同时cookie在浏览器可以被看到,不太安全,需要进行加密处理。
至于常用的web容器,tomcat和weblogic都有自己的session共享方案,后面再研究。