Nginx+Tomcat会话保持N种方案，各有千秋！你选择对了吗？

什么是会话保持?

会话保持又称作粘滞会话(Sticky Sessions)。会话保持是指在负载均衡器上的一种机制，可以识别客户端与服务器之间交互过程的关连性，在作负载均衡的同时还保证一系列相关连的访问请求都会分配到一台机器上。换句话讲，会话保持可使得来自同一IP的请求被转发到同一台后端服务器上。

为什么要会话保持?

确保在合适的情境下，将来自相同客户端的请求转发至后端相同的服务器进行处理。例如：你打开淘宝登录了个人账号，即使你浏览了再多的店铺宝贝，切换了很多的页面，用户名是不变的。如果服务器之间没有会话信息的同步机制，则其他服务器无法识别用户身份，造成用户在和应用系统发生交互时出现异常。

nginx+tomcat会话保持的方案有很多种，今天小编就同大家一起探讨下各种方案的优缺点，帮助大家选择出最适合自己业务的方案!

Nginx的ip_hash算法

Nginx中的ip_hash机制能够让某一客户端在相当长的一段时间内只访问固定的后端web服务器，会话就会得到保持。在某网站页面进行登录时，就不会在后端的web服务器之间跳来跳去，也不会出现登录一次的网站又提示重新登录的情况。

优点:

配置简单，在nginx.conf的upstream调度里增加一句ip_hash即可。

缺点:

1)nginx必须作为最前端的服务器，否则nginx无法获取到客户端准确的ip，以至不能根据ip作hash

2)如果nginx的后端还有其它负载均衡，将导致某个客户端的请求不能定位到同一台session应用服务器上

3)当后端tomcat宕机，用户session会丢失

适用场景：配置简单，利用hash函数解决session的问题，由于宕机导致session信息丢失，建议仅用于开发环境和测试环境。

另外，其它的负载均衡软件也有类似算法，比如LVS的sh算法，haproxy的source算法等

Tomcat集群的Session复制

tomcat的session复制分为两种，一种是全局式的(all-to-all)，也就是Node实例的session发生变化之后，它会将这些变更复制到其他所有集群组的成员;另一种是局部式的，它会用到BackupManager、BackupManager实现只复制给一个Buckup Node，并且这个Node会部署相同的Web应用。

tomcat的session复制是基于IP组播(multicast)来完成的。简单的说就是需要进行集群的tomcat通过配置统一的组播IP和端口来确定一个集群组，当一个node的session发生变更的时候，它会向IP组播发送变更的数据，IP组播会将数据分发给所有组里的其他成员(node)。

官方配置方式如下图：

地址：http://tomcat.apache.org/tomcat-7.0-doc/cluster-howto.html

优点:

当后端tomcat宕机，用户session不丢失。

缺点:

1)使用组播将信息复制到多个tomcat节点，网络开销大

2)消耗更多内存和带宽

适用场景：tomcat官方推荐，集群比较小时采用此方案。

用缓存集中管理session

在单独的服务器或服务器集群上使用缓存技术，如 Redis 存储Session数据，集中管理所有的Session，所有的Web服务器都从这个存储介质中存取对应的Session，实现Session共享。

目前常用的Session集中管理方案有两种，一种是Memcache-Tomcat-Session，另一种是Spring Session。

优点:

1)可靠性高，减少Web服务器的资源开销

2)提高session数据安全性

缺点:

1)太依赖缓存服务器

2)需要额外的缓存服务器，成本也高

3)实现上有些复杂，配置较多

适用场景：Web服务器较多、要求高可用性的情况。