欢迎大家关注 github.com/hsfxuebao ，希望对大家有所帮助，要是觉得可以的话麻烦给点一下Star哈
1. 为什么要使用Session共享？
稍大一些的网站，通常都会有好几个服务器，每个服务器运行着不同功能的模块，使用不同的二级域名，而一个整体性强的网站，用户系统是统一的，即一套用户名、密码在整个网站的各个模块中都是可以登录使用的。各个服务器共享用户数据是比较容易实现的，只需要在后端放个数据库服务器，各个服务器通过统一接口对用户数据进行访问即可。但还存在一个问题，就是用户在这个服务器登录之后，进入另一个服务器的别的模块时，仍然需要重新登录，这就是一次登录，全部通行的问题，映射到技术上，其实就是各个服务器之间如何实现共享 SESSION 数据的问题。
2. session工作原理
在解决问题之前，先来了解一下 SESSION 的工作原理。在客户端（如浏览器）登录网站时，被访问的 页面可以使用 session_start() 打开 SESSION，这样就会产生客户端的唯一标识 SESSION ID（此 ID 可通过函数 session_id() 获取/设置）。SESSION ID 可以通过两种方式保留在客户端，使得请求不同的页面时，程序可以获知客户端的 SESSION ID；一种是将 SESSION ID 自动加入到 GET 的 URL 中，或者 POST 的表单中，默认情况下，变量名为 JSESSIONID；另一种是通过 COOKIE，将 SESSION ID 保存在 COOKIE 中，默认情况下，这个 COOKIE 的名字为 JSESSIONID。这里我们主要以 COOKIE 方式进行说明，因为应用比较广泛。
服务端通过客户端传递的session_id区分用户，用来标记用户的登录状态。
用户再次发送请求的时候，把服务端返回的session_id通过cookie[或者URL传参]的形式传递到服务端，这样服务端就可以区分出来具体操作的用户。
3. 如何解决负载均衡之后的session共享问题
3.1 硬件方式
使用硬件F5做粘性会话(不会，只是知道可以这么干)，成本太高，后期也不好维护。
3.2 负载均衡的时候使用ip_hash算法进行分发
使用Nginx的ip_hash特性做粘性会话，可以让用户每次访问都转发到该用户第一次访问的web容器上，但是当该web容器上的应用挂了，nginx不会将该用户的请求转发到别的web容器，体验不好。
3.3 不使用session，换作cookie
基于cookie实现，将session直接存储到cookie中(安全问题，虽然可以加密存储，但是觉得不能将敏感数据放在客户端)
3.4 对session文件进行同步
使用同步工具对session文件进行同步，保证负载服务器的session文件都是一致的，这种做法虽然可以解决session共享的问题，同样的内容会存在多个服务器上，而且部分服务器存在的session文件可能从开始到结束完全没有使用到，浪费了服务器的资源。 【rsync，inotify-tools等】
3.5 容器插件
使用容器扩展来实现，大家比较容易接受的是通过容器插件来实现，比如基于Tomcat的memcached-session-manager / tomcat-redis-session-manager，基于Jetty的jetty-nosql-memcache / jetty-session-redis等等。好处是对项目来说是透明的，无需改动代码。不过前者目前还不支持Tomcat 8，或者说不太完善。此方法过于依赖容器，一旦容器升级或者更换意味着又得从新来过。并且代码不在项目中，对开发者来说维护也是个问题（如果你使用的是weblogic、jboss、websphere等商业web容器，根本没有这种第三方容器扩展，web容器换了厂商就不行了）。
3.6 使用memcache或者redis保存session信息
自己实现一套会话管理，将session读取/存储到Redis或其他nosql或数据库(网站用户量大的情况下，频繁dml数据，对db压力大)中。很显然这个方案灵活性最大，但开发需要一些额外的时间。弄懂了会挺不错的。
3.7 框架的会话管理工具 spring-session
第六种：使用框架的会话管理工具spring-session，可以理解是替换了Servlet那一套会话管理，既不依赖容器，又不需要改动代码，并且是用了spring-data-redis那一套连接池，可以说是最完美的解决方案。当然，前提是项目要使用Spring Framework才行。
3.8 shiro自带session(非httpsession)的权限框架
如果项目中使用shiro这种自带session(非httpsession)的权限框架，需要重写shiro的SessionDao将session存入redis(或其他)来实现session共享，可以自己重写(也不是很麻烦)或者找现成的(shiro-redis微笑脸，省的自己造轮子了，知道原理就行)。
3.9 总结
前三种方案：出于安全、成本(自己搞着玩不好弄)、无法完全做到7* 24* 365不宕机，个人不推荐。有兴趣的自己研究吧。剩下的五种方案大体思路其实都一样，存到nosql中(内存读写快)。
