一 简介
(以下内容由个人根据msm官网大意翻译,原文地址:http://code.google.com/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值类似:602F7397FBE4D9932E59A9D0E52FE178-n1 【其中n1为Memcached节点标识】
二 安装
参考网站:http://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration
环境
1. Linux 环境
2. Tomcat7.X (3台),在同一台机器上启动三台Tomcat需要修改conf/server.xml中的三个端口:8080,8005,8009
3. MemBase (1台),也可采用memcached,使用方法一样,只是在java客户端连接时有不同。
4. nginx
准备的jar包
注意:不同的tomcat版本(tomcat6,tomcat7)所需的包不一样,需要针对tomcat版本下载对应的包.
1.这是采用的最新稳定版1.6.1,序列化方式使用的是kryo,注意版本要求与msm版本基本一致,建议统一采用最新稳定版,如下。其中序列化方式是可选的。
2.这是采用的javolution的序列化方式所有需要的包
建议采用kryo序列化方式,效率更高。
配置
1. 将上面所提到的包全部拷贝到tomcat的lib下(三台tomcat都需要)
注意:当使用多台tomcat时,一定要使用non-sticky模式):
A:使用默认的sticky session,kryo序列化方式,memcached缓存
1. <Context>
2. ...
3. <Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
4. memcachedNodes="n1:host1.yourdomain.com:11211,n2:host2.yourdomain.com:11211"
5. failoverNodes="n1"
6. requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$"
7. transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"
8. />
9. </Context>
B:使用non-sticky session
1. <Context>
2.
3. ...
4.
5. <Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
6. memcachedNodes="n1:host1.yourdomain.com:11211,n2:host2.yourdomain.com:11211"
7. sticky="false"
8. sessionBackupAsync="false"
9. lockingMode="uriPattern:/path1|/path2"
10. requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$"
11. transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"
12. />
13.
14. </Context>
C:使用membase
1. <Context>
2.
3. ...
4.
5. <Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
6. memcachedNodes="http://host1.yourdomain.com:8091/pools"
7. username="bucket1"
8. password="topsecret"
9. memcachedProtocol="binary"
10. sticky="false"
11. sessionBackupAsync="false"
12. requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$"
13. transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"
14. />
15.
16. </Context>
当使用javolution序列化方式时将:
1. transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory”
替换为:
1. transcoderFactoryClass="de.javakaffee.web.msm.serializer.javolution.JavolutionTranscoderFactory"
配置完成后,分别启动tomcat,正常启动说明msm配置成功。
3. 最后附上nginx配置:
修改配置文件nginx\conf\nginx.conf
1. 找到内容server {
在它的上面加入如下内容:
1. upstream 10.6.53.120 {
2. ip_hash; ----#ip_hash策略将同一IP的所有请求都转发到同一应用服务器
3. server 10.6.53.120:8080;---------我的tomcat端口号
4. server 10.6.53.120:7080;
5. server 10.6.53.120:6080;
6. }<span>(</span><span>这是负载切换使用的服务器网站</span><span>IP)</span>
2. 找到
1. location / {
2. root html;
3. index index.html index.htm;
4. }
把内容更改如下:
1. location / {
2. proxy_pass http://10.6.53.120
3. proxy_redirect default;
4. proxy_connect_timeout 10; added by me(跟代理服务器连接的超时时间,必须留意这个time out时间不能超过10秒.当一台服务器当掉时,过10秒转发到另外一台服务器)
5. }
3. 找到
1. server {
2. listen 80;
3. server_name localhost;
server {listen 80;server_name localhost;
把内容改成如下:
1. server {
2. listen 80;
3. server_name 10.6.53.120;
(这是监听访问域名绑定那台服务器80端口的请求)
到这里所有的配置已经完成,现在准备一个简单的web工程,并分别部署到三台tomcat下。启动memcached(membase),启动三台tomcat,启动nginx,然后在地址栏输入url地址,看能否成功访问。关闭其中一台tomcat,看是否仍然能够正常访问,能够则说明配置nginx配置成功。
三 原理
MSM(memcached-session-manager) 支持tomcat6 和tomcat7 ,利用 Value(Tomcat 阀)对Request进行跟踪。Request请求到来时,从memcached加载session,Request请求结束时,将tomcat session更新至memcached,以达到session共享之目的, 支持 sticky 和 non-sticky 模式。需要注意的是使用sticky模式时需要配置jvmroute参数,配置方式如下:
配置$CATALINA_HOME/conf/server.xml
1. <Engine name="Catalina"defaultHost="localhost"jvmRoute="tomcat2">
<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 为主 sessionmemcached 2 为备session。Request请求到来时,从memcached 2加载备 session 到 tomcat,(当 容器 中还是没有session 则从memcached1加载主 session 到 tomcat, 这种情况是只有一个memcached节点,或者有memcached1 出错时),Request请求结束时,将tomcat session更新至 主memcached1和备memcached2,并且清除tomcat session 。以达到主备同步之目的,如下是non-sticky模式的响应流程图:(图片来源网络)。