Tomcat利用MSM实现Session共享方案解说

 

Session共享有多种解决方法,常用的有四种:
1)客户端Cookie保存
2)服务器间Session同步
3)使用集群管理Session(如MSM)
4)把Session持久化到数据库

针对上面Session共享四种方法的详解:
1)客户端Cookie保存以cookie加密的方式保存在客户端.优点是减轻服务器端的压力,每次session信息被写在客服端,然后经浏览器再次提交到服务器。即使两次请求在集群中的两台服务器上完成,也可以到达session共享。
2)将session持久化到数据中这种共享session的方式即将session信息存入数据库中,其它应用可以从数据库中查出session信息。目前采用这种方案时所使用的数据库一般为mysql。 利用数据库共享 session 的方案有一定的实用性,但也有如下缺点:首先 session 的并发读写在数据库中完成,对 mysql 的性能要求比较高;其次,我们需要额外地实现 session 淘汰(超时)逻辑代码,即定时从数据库表中更新和删除 session 信息,增加了工作量。
3)使用服务器间session同步使用主-从服务器的架构,当用户在主服务器上登录后,通过脚本或者守护进程的方式,将session信息传递到各个从服务器中,这样用户访问其它的从服务器时,就可以读到session信息。 缺点:比如速度慢、不稳定等,另外,如果 session 信息传递是主->从单向的,会有一些风险,比如主服务器down了,其它服务器无法获得 session 信息
4)使用集群统一管理Session提供一个集群保存session共享信息.其他应用统统把自己的session信息存放到session集群服务器组。当应用系统需要session信息的时候直接到 session 集群服务器上读取。目前大多都是使用 Memcache 来对 Session 进行存储。

以Memcache来实现Session共享的方式目前比较流行的有两种实现方案:
     a)使用Filter方式:此方式使用过滤器的方式重新对httpRequest 对象进行了包装,并加入memcached客户端,此方式的优点是:使用简单,把过滤器配置进去即可,另外比较灵活,因为它是在客户端实现的,配置比较灵活,而且服务器无关,你可以在任何支持servlet的容器上部署。
     b)使用Memcached-Session-Manager,俗称MSM,是一个用于解决分布式 tomcat 环境下 session 共享的问题的开源解决方案。它的实现原理为以tomcat插件的方式部署在服务器,修改了 servlet 容器代码中的 session 相关代码,使其连接 memcached ,在 memcached 中创建和更新session。

MSM为什么要产生?
通常来说,对于一些大型的web2.0的网站,在正式部署时一般是部署在不同故障域的多台应用服务器上,以j2ee应用为例,一般都会部署在tomcat下。假如部署了10台tomcat服务器,那这10台tomcat可能是部署在不同的机器上,然后将应用程序copy到这10台tomcat下,然后启动所有tomcat。一般来说这样做的目的是为了达到负载均衡以及避免单点故障,另外也考虑到国内网络环境的原因,避免跨网络运营商访问而导致访问速度低下的问题,当然不要忘了坐镇这10台tomcat前端的还有我们的反向代理服务器。比如nginx,这个就是另一个话题了,下面主要讲的是,对于这种分布式tomcat环境,如何保证session 的唯一性??
一般来说,大体的解决方案是通过编写一段代码或者通过配置tomcat的filter,将产生的session放到同一个内存数据库中,事实上这确实可行的。然而这种问题应该有更省事更成熟的解决方案,也就是将要说的Memcached_Session_Manager,简称msm,这就是一个用于解决分布式tomcat环境下session共享的问题的开源解决方案。

MSM(即memcached session manager)是一个高可用Tomcat session共享解决方案,除了可以从本机内存快速读取Session信息(仅针对黏性Session)外,还可使用memcached存取Session,以实现高可用。
对于非黏性Session,memcached直接存储session。除memcached外,还可以其他缓存组件如memcachedb, membase等。

MSM特性:
. 支持黏性、非黏性Session
. 无单一故障点
. 可处理tomcat故障转移
. 可处理memcached故障转移
. 插件式session序列化
. 允许异步保存session,以提升响应速度
. 只有当session有修改时,才会将session写回memcached
. JMX管理&监控

MSM解决的问题假设有一个Tomcat集群,使用黏性session,如何应对单点故障问题?
为了应对更多的并发量和可用性,可以不断的增加Tomcat节点,但是单点故障仍旧会是个问题:
如果使用黏性Session,一个Tomcat故障时,其他Tomcat并不能接管故障Tomcat节点的Session。
解决此问题的思路就是将黏性Session同时保存在Memcached中,如果单个Tomcat发生故障,集群中的其他Tomcat可以从Memcached中得到Session信息。
注意:对于非黏性Session,MSM V1.4.0及以后版本已经支持。

--------------------------------------------------------------------------------------------------------------------------------------------
黏性Session和非粘性Session,一般用于tomcat服务集群,二者的区别是:

1)黏性Session(即sessionsticky,不复制Session会话):
此模式下同一会话中的请求都被派送到同一个tomcat实例上,这样就无须在多台服务器之间实现session共享了,这是其好处。
不好的地方就是不能实现failureover(故障切换)了,一但用户访问的机器挂掉,那么其session就会丢失。

也就是说当用户发出第一个request后,负载均衡器动态的把该用户分配到某个节点,并记录该节点的路由,以后该用户的所有request都绑定到这个路由,
用户只会与该server发生交互,这种策略被称为粘性session。

这种方式将同一用户的请求转发到特定的Tomcat服务器上,避免了集群中Session的复制,缺点是用户只跟一种的一台服务器通信,如果此服务器down掉,那就废了。

2)非黏性Session(即sessionreplication,复制Session会话)此模式下同一会话中的请求可以被分配到不同的tomcat实例上进行处理,此时就需要在不
同服务器之间同步、复制session,这样一来即使一台服务器挂掉了,请求在其它服务器上照样可以访问到session信息,其缺
点在于Session复制需要系统资源和网络开销。
-------------------------------------------------------------------------------------------------------------------------------------------------

MSM如何工作?
首先谈下tomcat故障转移
msm安装在tomcat里,tomcat会在本地保留所有会话信息就像StandardManager一样。此外,一个请求完成后,session会被备份到memcached节点。 当服务同一会话的下一次请求时,tomcat可以在本地找到这个会话数据,同一会话的第二次请求 处理完后,会话数据会更新到memcached节点。 假设处理某个会话的tomcat挂了。 那么下次请求会被路由到另一个tomcat。而这个tomcat没有在本地保存该会话的数据。因此它会去相应的memcached(根据请求头中sessionid的后缀,后面配置$CATALINA_HOME/conf/context.xml时,memcachedNodes="n1:localhost:11211,n2:localhost:11212",就是n1,n2)中查找此次请求的会话数据并保存到本地。 这样这个tomcat就可以处理此次会话了。当这个tomcat处理完此次会话,它会将更新相应memcached节点存储的session信息。

如下图tomcat1故障,路由到tomcat2由负载均衡完成(如nginx)。

再说下memcahced故障转移
msm也实现了memcached的故障转移。当一个memcached节点不可用时,session信息就会被转移到其他memcached节点。 与此同时,sessionid会被修改,一个新的JESESSIONID(响应头会有Set-Cookie:JESSIONID;XXXXXXXXXXXXX)会被发送 到浏览器端。当使用粘性session(sticky session)时,确保你的负载均衡不会给sessionid添加后缀。

SESSIONID的格式
MSM知道Memcached节点列表,这些节点标识会存储在SESSIONID中,SESSIONID值类似:602F7397FBE4D9932E59A9D0E52FE178-n1 【其中n1为Memcached节点标识】

MSM原理
MSM利用Value(Tomcat 阀)对Request进行跟踪。Request请求到来时,从memcached加载session,Request请求结束时,将tomcat session更新至memcached,以达到session共享之目的,支持sticky(粘性)和non-sticky(非粘性)模式。需要注意的是使用sticky模式时需要配置jvmroute参数,配置方式如下:
配置$CATALINA_HOME/conf/server.xml

<Engine name="Catalina"defaultHost="localhost"jvmRoute="tomcat2">  

注意每台tomcat的jvmroute参数都不能一样。

Sticky 模式:
tomcat session为主session,memcached为备session。Request请求到来时,从memcached加载备session到tomcat (仅当tomcat jvmroute发生变化时,否则直接取tomcat session);Request请求结束时,将tomcat session更新至memcached,以达到主备同步之目的。
下面是sticky模式时响应的流程图:

Non-Sticky模式:
tomcat session为中转session,memcached1为主session,memcached2为备session。Request请求到来时,从memcached2加载备session到tomcat,(当容器中还是没有session,则从memcached1加载主session到tomcat,这种情况是只有一个memcached节点,或者有memcached1出错时),Request请求结束时,将tomcat session更新至主memcached1和备memcached2,并且清除tomcat session,以达到主备同步之目的。
如下是non-sticky模式的响应流程图:

posted @ 2017-02-15 13:23  散尽浮华  阅读(3666)  评论(0编辑  收藏  举报