当项目使用分布式时，session问题就显得比较突出了，因为有不同服务器的缘故，如果你安照一般方式存储session，那么你的session会保存在某一台服务器上，如果你的下一个请求并不是访问这台服务器，那么会发生读取不到session的情况。这种情况的解决方案有许多种，例如你可以采用session sticky的方式，但是这样会对负载均衡器造成相当大的负担，而且某台服务器挂了，会造成session丢失。或者采用session replication方式，但是如果服务器数量一多，是不是就造成了十分庞大的带宽开销，而且，如果有很多客户端同时访问服务器的话，那么每台服务器都需要保存大数量的session数据，而session数据是存储在内存中的，这样每台机器用于保存session数据占用的内存就太多了。还有一种就是采用cookie，不过这种方式是十分不可取了，先不说session数据放到客户端那边造成的安全问题，这样会造成带宽消耗，而且会强烈影响性能，而且cookie自身也有长度限制。而另外一种方式则是session 集中化处理，你可以存在数据库中，也可以采用其他分布式存储系统，这里session的储存引入了网络操作，所以可能会有数据延迟，而且当session储存设备挂了，会造成所有session丢失，不过总体来说，这种session的存储方式是十分明显的。而这里我们采用redis，nosql的方式进行session存储。

而使用redis存储的实现方案有好多种，这里介绍一下。

• 第一种是使用容器拓展来实现，一般都是通过容器插件来实现，例如基于Tomcat的tomcat-redis-session-manager，基于Jetty的jetty-session-redis等等。好处是对项目来说是透明的，无需更改代码，但是目前还不支持Tomcat8。个人觉得由于过于依赖容器，，一旦更换容器或者容器升级，那又得重新来过。而且代码并不在项目中，对于开发者的维护也是个麻烦。
• 第二种是自定义会话管理的工具类，这样的话灵活性很大，可以根据自身需求来实现，但是需要额外的开发时间
• 第三种是使用框架的会话管理工具，例如spring-session，shiro等，可以理解是替换了servlet那一套会话管理，不依赖容器，不用改动代码。如果采用spring-session的话，使用的是spring-data-redis那一套连接池，prefect，不过前提是你得用spring框架。至于shiro，那是一个十分成熟，强大易用的安全框架，学习成本比spring-session来的要多一些。

在下篇文章中，将写一下使用容器拓展实现redis session存储…