分布式session处理方式

感谢：http://blog.csdn.net/u010028869/article/details/50773174?ref=myread

前言

在搭建完集群环境后，不得不考虑的一个问题就是用户访问产生的session如何处理。若是不作任何处理的话，用户将出现频繁登陆的现象，好比集群中存在A、B两台服务器，用户在第一次访问网站时，Nginx经过其负载均衡机制将用户请求转发到A服务器，这时A服务器就会给用户建立一个Session。当用户第二次发送请求时，Nginx将其负载均衡到B服务器，而这时候B服务器并不存在Session，因此就会将用户踢到登陆页面。这将大大下降用户体验度，致使用户的流失，这种状况是项目毫不应该出现的。

咱们应当对产生的Session进行处理，经过粘性Session，Session复制或Session共享等方式保证用户的体验度。

如下我将说明5种Session处理策略，并分析其优劣性。

 

第一种：粘性session

原理：粘性Session是指将用户锁定到某一个服务器上，好比上面说的例子，用户第一次请求时，负载均衡器将用户的请求转发到了A服务器上，若是负载均衡器设置了粘性Session的话，那么用户之后的每次请求都会转发到A服务器上，至关于把用户和A服务器粘到了一块，这就是粘性Session机制。

优势：简单，不须要对session作任何处理。

缺点：缺少容错性，若是当前访问的服务器发生故障，用户被转移到第二个服务器上时，他的session信息都将失效。

适用场景：发生故障对客户产生的影响较小；服务器发生故障是低几率事件。

实现方式：以Nginx为例，在upstream模块配置ip_hash属性便可实现粘性Session。

upstream mycluster{
    #这里添加的是上面启动好的两台Tomcat服务器
    ip_hash;#粘性Session
     server 192.168.22.229:8080 weight=1;
     server 192.168.22.230:8080 weight=1;
}

• 1
• 2
• 3
• 4
• 5
• 6

 

第二种：服务器session复制

原理：任何一个服务器上的session发生改变（增删改），该节点会把这个 session的全部内容序列化，而后广播给全部其它节点，无论其余服务器需不须要session，以此来保证Session同步。

优势：可容错，各个服务器间session可以实时响应。

缺点：会对网络负荷形成必定压力，若是session量大的话可能会形成网络堵塞，拖慢服务器性能。

实现方式：

① 设置tomcat ，server.xml 开启tomcat集群功能 

 

Address:填写本机ip便可，设置端口号，预防端口冲突。

② 在应用里增长信息：通知应用当前处于集群环境中，支持分布式 
在web.xml中添加选项 <distributable/>

 

第三种：session共享机制

使用分布式缓存方案好比memcached、redis，可是要求Memcached或Redis必须是集群。

使用Session共享也分两种机制，两种状况以下：

① 粘性session处理方式

原理：不一样的 tomcat指定访问不一样的主memcached。多个Memcached之间信息是同步的，能主从备份和高可用。用户访问时首先在tomcat中建立session，而后将session复制一份放到它对应的memcahed上。memcache只起备份做用，读写都在tomcat上。当某一个tomcat挂掉后，集群将用户的访问定位到备tomcat上，而后根据cookie中存储的SessionId找session，找不到时，再去相应的memcached上去session，找到以后将其复制到备tomcat上。

 

 

② 非粘性session处理方式

原理：memcached作主从复制，写入session都往从memcached服务上写，读取都从主memcached读取，tomcat自己不存储session

 

 

优势：可容错，session实时响应。

实现方式：用开源的msm插件解决tomcat之间的session共享：Memcached_Session_Manager（MSM）

a. 复制相关jar包到tomcat/lib 目录下

JAVA memcached客户端：spymemcached.jar

msm项目相关的jar包：

1. 核心包，memcached-session-manager-{version}.jar
2. Tomcat版本对应的jar包：memcached-session-manager-tc{tomcat-version}-{version}.jar

序列化工具包：可选kryo，javolution,xstream等，不设置时使用jdk默认序列化。

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9

b. 配置Context.xml ，加入处理Session的Manager

粘性模式配置： 

 

非粘性配置： 

 

第四种：session持久化到数据库

原理：就不用多说了吧，拿出一个数据库，专门用来存储session信息。保证session的持久化。

优势：服务器出现问题，session不会丢失

缺点：若是网站的访问量很大，把session存储到数据库中，会对数据库形成很大压力，还须要增长额外的开销维护数据库。

 

第五种terracotta实现session复制

原理：Terracotta的基本原理是对于集群间共享的数据，当在一个节点发生变化的时候，Terracotta只把变化的部分发送给Terracotta服务器，而后由服务器把它转发给真正须要这个数据的节点。能够当作是对第二种方案的优化。

 

 

优势：这样对网络的压力就很是小，各个节点也没必要浪费CPU时间和内存进行大量的序列化操做。把这种集群间数据共享的机制应用在session同步上，既避免了对数据库的依赖，又能达到负载均衡和灾难恢复的效果。

实现方式：篇幅缘由，下篇再论。

 

小结

以上讲述的就是集群或分布式环境下，session的5种处理策略。其中就应用普遍性而言，第三种方式，也就是基于第三方缓存框架共享session，应用的最为普遍，不管是效率仍是扩展性都很好。而Terracotta做为一个JVM级的开源群集框架，不只提供HTTP Session复制，它还能作分布式缓存，POJO群集，跨越群集的JVM来实现分布式应用程序协调等，也值得学习一下。