2015集群.docVIP

MSM--Memcached_Session_Manager介绍及使用 我们都知道对于一些大型的web2.0的网站，在正式部署时一般是部署在不同故障域的多台应用服务器上，以j2ee应用为例，一般我们都会部署在tomcat下，假如我们部署了10台tomcat服务器，那这10台tomcat可能是部署在不同的机器上，然后将应用程序copy到这10台tomcat下，然后启动所有tomcat，一般来说这样做的目的是为了达到负载均衡以及避免单点故障，另外也考虑到国内网络环境的原因，避免跨网络运营商访问而导致访问速度低下的问题，当然不要忘了坐镇这10台tomcat前端的还有我们的反向代理服务器，比如nginx，这个就是另一个话题了，我今天主要讲的是，对于这种分布式tomcat环境，我们如何保证session 的唯一性（我假定你知道session是什么）。这也是在日期公司的一个项目中负责解决的一个问题，当然实际上这并不是什么新的议题，之前就有很多解决方案，但是一般来说的大体的解决方案是自己通过编写一段代码或者通过配置tomcat的filter，将产生的session放到同一个内存数据库中，事实上这确实可行的，只不过我比较懒，我总是觉得这种问题应该有更省事更成熟的解决方案，那确实是有的，也就是我马上介绍的?Memcached_Session_Manager，简称msm，这就是一个用于解决分布式tomcat环境下session共享的问题的开源解决方案。 一 简介 （以下内容由个人根据msm官网大意翻译，原文地址：/p/memcached-session-manager/） ?引言 MSM--memcached session manager是一个高可用的Tomcat session共享解决方案，除了可以从本机内存快速读取Session信息(仅针对黏性Session)外，同时可使用memcached存取Session，以实现高可用。 对于非黏性Session，memcached直接存储session。 除memcached外，还可以其他缓存组件如memcachedb,?membase等。 ?特性 ? ?支持Tomcat6、Tomcat7 ?支持黏性、非黏性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及以后版本已经支持。 MSM如何工作 ? ? ?【注】以下论述仅针对黏性Session 安装在Tomcat上的MSM使用本机内存保存session，和StandardManager一样。另外，当一个请求结束时，session会被送回Memcached进行备份。当下一次请求开始时，本地Session可用，直接服务，请求结束后，session又被送回Memcached备份。 当集群中的一个Tomcat挂掉，下一次请求会被路由到其他Tomcat上。负责处理此此请求的Tomcat并不清楚Session的信息。此时它会从Memcached查找该Session，更新该Session并将其保存在本机内容。此次请求结束，session被修改，送回Memcached备份。 ? ? . What else？ 上边介绍的是处理Tomcat故障转移，MSM又是如何处理Memcached故障转移呢？ 如果一个Memcached故障，当前Memcached中的Session会转移到其他Memcached节点，同时，JSESSIONID被修改并送回浏览器。 如果使用黏性Session，应确保loadbalancer中配置生成的JSESSIONID无任何后缀。 SESSIONID的格式 MSM知道Memcached节点列表，这些节点标识会存储在SESSIONID中，SESSIONID值类似：602F7397FBE4D99