Tomcat7配Redis，性能蹭蹭往上涨，Web应用也能飞起来

（引用来源：CSDN博客《Tomcat7整合Redis实现Session共享，性能优化实战》）

之前我们那个Web应用,用的是Tomcat7自带的session管理，就是用户登录后，Tomcat会在自己内存里给这个用户划出一块地方存东西，比如用户名、购物车信息，平时访问量小的时候没啥感觉，反正服务器内存够用，但后来用户越来越多，问题就暴露出来了。

最头疼的有两点,第一是服务器压力一大，Tomcat自己就有点扛不住了，特别是session里面存的东西多了大了以后，每次读写session都变得有点慢，感觉整个网页响应速度都拖沓了，第二就是如果我们想多开几台Tomcat服务器做集群，搞负载均衡，麻烦就大了，因为用户第一次访问被分到A服务器登录了，session存在A上；下次请求万一被负载均衡器分到B服务器，B服务器上根本没有这个用户的session，就会认为用户没登录，又让人家重新登录，体验特别差，当时我们试过Tomcat自带的集群session复制功能，就是让几台Tomcat之间互相同步session数据，结果发现同步来同步去，网络开销特别大，反而严重拖慢了性能，根本不行。

（引用来源：开源中国社区一篇关于分布式Session管理的讨论帖）

后来我们就开始找解决方案,目标很明确：要把session从Tomcat自己的内存里挪出来，放到一个独立、高速、并且所有Tomcat服务器都能访问到的地方，挑来挑去，选中了Redis，Redis这东西，简单说就是个速度特别快的内存数据库，数据主要放在内存里读写，所以比从硬盘读写的传统数据库快太多了，正好符合我们对session存储要“快”的要求。

具体怎么做呢？我们当时用了一个叫Tomcat Redis Session Manager的插件，配置起来不算太复杂，大概就是改改Tomcat的配置文件，告诉Tomcat：以后别自己管session了，session的增删改查都交给Redis来处理，我们得配置好Redis服务器的地址、端口号（默认是6379），如果有密码也得配上，然后把这个插件的jar包放到Tomcat的lib目录下就行了。

（引用来源：GitHub上Tomcat Redis Session Manager项目的README文档）

这样配置好之后,效果是立竿见影的，最直观的感受就是Tomcat本身变轻快了，因为它不用再在自己的内存里维护一大堆session对象了，内存压力骤减，Tomcat可以更专心地去处理HTTP请求和响应，处理业务逻辑，响应速度自然就上去了，感觉就像是给Tomcat卸下了一个沉重的大包袱，让它能轻松上阵跑步前进了。

session读写速度反而更快了,可能有人会觉得，从本地内存读改成通过网络访问Redis，会不会变慢？因为Redis是专门为高速读写设计的，而且通常部署在和Tomcat服务器同一个机房内网，网络延迟极低，再加上Redis本身极高的性能，最终平均下来，读写session的速度比原来Tomcat自己管理时还要快，尤其是在session数据量比较大的情况下，优势更明显，用户那边感受到的就是网页跳转、操作响应非常流畅，“飞起来”有点夸张，但确实顺滑了很多。

最大的好处还是为我们后续扩展铺平了道路,当我们用户量再上一个台阶，需要增加第二台、第三台Tomcat服务器时，简直太简单了，只需要在新的Tomcat服务器上同样配置好连接同一个Redis服务器，那么无论用户的请求被分发到哪一台Tomcat上，都能从同一个Redis里拿到session信息，彻底解决了之前session丢失的问题，实现负载均衡变得轻而易举，系统的扩展性大大增强。

（引用来源：团队内部项目性能监测报告数据对比）

我们还顺便解决了一个小问题：session的持久化，Tomcat默认session是存在内存里的，一旦服务器重启或者崩溃，所有用户都会被迫退出登录，而Redis可以配置成定期把数据持久化到硬盘上，这样即使Redis重启，也能从硬盘恢复session数据，实现了session的持久化，提高了服务的可靠性。

这么做也不是一点代价都没有,我们变得依赖Redis了，Redis必须要保证高可用，万一Redis服务器宕机，所有Tomcat就都取不到session了，整个网站登录状态会全部失效，所以后来我们又给Redis做了主从复制和哨兵机制，确保Redis服务本身的高可用性。

这次把Tomcat7的session管理切换到Redis,可以算是一次非常成功的性能优化实践，它不仅直接提升了单台Tomcat的处理能力和响应速度，更重要的是为Web应用的水平扩展提供了坚实的基础，让我们的应用真正具备了应对高并发、大流量挑战的能力。