问题的由来：访问一个网站时，有两类请求。一种请求叫做无状态的请求，一种请求叫做有状态。

无状态，例如：登录页面，类似这种页面，哪个tomcat给我们响应都是一样的，不需要区分。这是我们最喜欢的。集群的动态伸缩性（增加节点，移除节点）。

有状态，例如：系统登录后，假如用户的请求被转发到tomcat1上，这时系统会写一个当前用户的信息放入session中。这种情况就称为有状态的，问题就来了。nginx负载均衡后，下一次用户的请求就被转发tomcat2上。tomcat2上没有session。系统就会要求用户去登录，这显然是不合理的。把这个问题称作session共享问题。

解决的办法：

1. session同步

tomcat支持动态将某个tomcat下的session复制到其他的tomcat中。但是这个方式是早期的企业级应用习惯的方式。现在很少使用。

这种方式在集群数量很少时，结果还是可以的。但如果集群数量庞大。都需要复制session，这时会因为网络延迟，或者session的内容非常大。都会造成隐患，这时可能读到脏数据。

2 Session黏着-放在服务端

对ip地址或者域名地址进行hash；或者uri进行hash。

缺点：用户浏览器的IP地址hash以后满足单调性。会可能造成资源的分配不均衡，负载均衡就达不到到目的。有的服务器负载过重，有的服务器负载过轻，显然没有充分利用资源。

因为uri比ip地址相应数量多，变化就多，因此uri-hash比ip-hash分布更均衡些。uri-hash需要第三方软件支持pcre-8.02.tar.gz、Nginx_upstream_hash-0.3.1.tar.gz

3 将信息放到cookie-放在客户端

session存在服务器端，会对服务器产生压力。如果将信息保存到cookie中，减轻了服务器的压力，同时每个客户端的压力也很小。因为只保存自己的信息。这种方式在实际的开发中广泛的采用。

缺点：cookie可以被禁用，cookie要随着浏览器传递，增大了传输的内容，cookie大小有限制。

4 终极的解决方案-新SSO单点登录

将session从系统中独立出来。Apacheshiro顶级安全框架，它的session管理就是独立出来的。目前主流做法是利用redis作为session管理的实现，因为redis访问极其快速。