1、：使用硬件F5做粘性会话(不会，只是知道可以这么干)，成本太高，后期也不好维护。

         2、：使用Nginx的ip_hash特性做粘性会话，可以让用户每次访问都转发到该用户第一次访问的web容器上，但是当该web容器上的应用挂了，nginx不会将该用户的请求转发到别的web容器，体验不好。

         3、：基于cookie实现，将session直接存储到cookie中(安全问题，虽然可以加密存储，但是觉得不能将敏感数据放在客户端)

        4、：使用容器扩展来实现，大家比较容易接受的是通过容器插件来实现，比如基于Tomcat的memcached-session-manager / tomcat-redis-session-manager，基于Jetty的jetty-nosql-memcache / jetty-session-redis等等。好处是对项目来说是透明的，无需改动代码。不过前者目前还不支持Tomcat 8，或者说不太完善。此方法过于依赖容器，一旦容器升级或者更换意味着又得从新来过。并且代码不在项目中，对开发者来说维护也是个问题（如果你使用的是weblogic、jboss、websphere等商业web容器，根本没有这种第三方容器扩展，web容器换了厂商就不行了）。

        5、：自己实现一套会话管理，将session读取/存储到Redis或其他nosql或数据库(网站用户量大的情况下，频繁dml数据，对db压力大)中。很显然这个方案灵活性最大，但开发需要一些额外的时间。弄懂了会挺不错的。

　　6、：使用框架的会话管理工具spring-session，可以理解是替换了Servlet那一套会话管理，既不依赖容器，又不需要改动代码，并且是用了spring-data-redis那一套连接池，可以说是最完美的解决方案。当然，前提是项目要使用Spring Framework才行。

　　7、：如果项目中使用shiro这种自带session(非httpsession)的权限框架，需要重写shiro的SessionDao将session存入redis(或其他)来实现session共享，可以自己重写(也不是很麻烦)或者找现成的(shiro-redis微笑脸，省的自己造轮子了，知道原理就行)。