目录
1、测试环境概述
2、MSM简介
2.1、MSM的特性
2.2、MSM要解决的问题
2.3、MSM的工作原理
3、环境搭建
3.1、memcached安装
3.2、jdk与tomcat安装配置
3.3、MSM sticky session + kryo模式的配置
3.4、MSM no-sticky session + kryo模式的配置
4、思考与总结
1、测试环境概述
采用两台linux x64主机,主机上分别安装memcached与tomcat,memcached提供key/value的存储服务,tomcat提供jsp程序的web容器,两主机关闭iptables,关闭selinux。
主机规划如下:
主机1
IP地址:192.168.0.201
主机名:nod2.tes.com 别名:nod2
安装服务:jdk、tomcat、memcached
主机2
IP地址:192.168.0.202
主机名:nod3.tes.com 别名:nod3
安装服务:jdk、tomcat、memcached
简易拓扑如下:
<tomcat1> <tomcat2>
. \ / .
. X .
. / \ .
<memcached1> <memcached2>
2、MSM简介
MSM全称为Memcached Session Manager(Memcached会话管理器),是tomcat的用户session信息存放在像memcached这样的兼容key/value存储里的高可用解决方案,这里常使用的key/value服务有memcached与membase两种。
2.1、MSM的特性MSM的特性
a、支持tomcat 6,tomcat 7,tomcat 8
b、支持sticky session或no-sticky session
c、无单点故障
d、tomcat故障转移
e、memcached故障转移
f、附带串行化插件
g、支持异步session存储,拥有更快的性能
....
2.2、MSM要解决的问题
假如有一个web app运行在一个tomcat集群中,前端通过apache的mod_jk或mod_proxy实现tomcat的负载均衡集群,你想实现用户session的故障转移,从而达到用户session信息的不丢失。在前边的博文中已提出了一个“集群/session复制”的解决方案(博文地址:http://zhaochj.blog.51cto.com/368705/1650728),此种方案有一个缺点,当tomcat集群节点多余4或5个时,集群的性能就可能达到一个瓶颈,因其内部的session复制的实现是通过组播实现,对网络的压力很大,官方建议此种方案只适合小规格集群的环境中。而MSM能真正的解决这个问题,是session会话共享的一个可伸缩性解决方案,MSM是把用户的session信息存放在memcached中,假如一个tomcat节点死掉,其他的tomcat节点将接管工作并从后端的memcached服务器中取得之前的session信息,这保证了用户会话不会丢失,而后端的memcached的节点可以不只一个,配置多个memcached节点又保证了memcached的单点故障。
2.3、MSM的工作原理
MSM支持两种工作模式,sticky session和no-sticky session(从memcached-session-manager-1.4.0开始支持no-sticky session)。
sticky session模式:
安装了MSM的tomcat会优先使用本机内存保存session,当一个请求结束后,MSM会把session发送到memcached节点上存放以作备份,第二次请求时,如果本地有session就直接返回,第二次请求结束,把session修改后的信息更新到后端的memcached服务器,以这样的方式来保持本地的session与memcached上的session同步。当这个tomcat节点宕机时,那么用户的下一次请求就会被前端的负载均衡器路由到另一个tomcat节点上,而这个节点上并没有这个用户的session信息,这个节点就从memcached服务器上去读取session,并把session保存到本地的内存,当请求结束,session又被修改,再送回到memcached进行存放备份。结合下边的图就更能理解MSM基于sticky session的工作原理。
注:图片来自网络
另外,当后端配置了多台memcached时,MSM在更新session信息时会同时向多个memcached节点更新session,当一个memcached节点故障时,tomcat可以从选择一个正常工作的memcached节点读取session信息来发送给用户的浏览器,让其重置session信息,这样,memcached也达到了高可用的目的。
no-sticky session模式:
假设后端配置了两个memcached服务器,memcached1和memcached2,在这种配置的配置方法中没有发现有能设置哪个memcached是主,哪个是备,所以我猜想是MSM自身来确定哪个是主,哪个是备,为了描述no-sticky sessio的工作过程,假设memcahced1是主,memcached2是备。当请求到来时,MSM从memcached2(备)上读取session信息,如果没有就从memcached1(主)上读取,如果有那就读取到本地,如果没有那就在本地创建session,当请求结束时,把本地的session信息写回到memcached1和memcached2,并且要清除本地的session。结合下边的图,更能理解此模式的工作原理:
注:图片来自网络
3、环境搭建
3.1、memcached安装
在yum源中的memcached的版本也比较新,所以直接采用yum进行安装,如下:
[root@nod2 ~]# yum -y install memcached
[root@nod2 ~]# service memcached start
在nod3上依然采取yum安装,略。
3.2、jkd与tomcat安装配置
[root@nod2 msm]# pwd /root/software/msm [root@nod2 msm]# ls apache-tomcat-7.0.62.tar.gz jdk-8u45-linux-x64.rpm msm_kryo_serializers [root@nod2 msm]# ls msm_kryo_serializers/ asm-3.2.jar memcached-session-manager-1.8.3.jar msm-kryo-serializer-1.8.3.jar kryo-1.04.jar memcached-session-manager-tc7-1.8.3.jar reflectasm-1.01.jar kryo-serializers-0.11.jar minlog-1.2.jar spymemcached-2.11.1.jar
上边的这些jar包分为两类,一类是关于msm的包:
memcached-session-manager-1.8.3.jar
memcached-session-manager-tc7-1.8.3.jar
另一类是kryo序列化的jar包:
asm-3.2.jar msm-kryo-serializer-1.8.3.jar kryo-serializers-0.11.jar minlog-1.2.jar spymemcached-2.11.1.jar kryo-1.04.jar reflectasm-1.01.jar
这些包的下载地址在这里http://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration
[root@nod2 msm]# rpm -ivh jdk-8u45-linux-x64.rpm [root@nod2 msm]# /usr/java/latest/bin/java -version java version "1.8.0_45" Java(TM) SE Runtime Environment (build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode) [root@nod2 msm]# vim /etc/profile.d/java.sh JAVA_HOME=/usr/java/latest PATH=$JAVA_HOME/bin:$PATH export JAVA_HOME PATH [root@nod2 msm]# source /etc/profile.d/java.sh [root@nod2 msm]# tar xf apache-tomcat-7.0.62.tar.gz -C /usr/local/ [root@nod2 msm]# cd /usr/local/ [root@nod2 local]# ln -sv apache-tomcat-7.0.62 tomcat [root@nod2 local]# /usr/local/tomcat/bin/catalina.sh version Using CATALINA_BASE: /usr/local/tomcat Using CATALINA_HOME: /usr/local/tomcat Using CATALINA_TMPDIR: /usr/local/tomcat/temp Using JRE_HOME: /usr/java/latest Using CLASSPATH: /usr/local/tomcat/bin/bootstrap.jar:/usr/local/tomcat/bin/tomcat-juli.jar Server version: Apache Tomcat/7.0.62 Server built: May 7 2015 17:14:55 UTC Server number: 7.0.62.0 OS Name: Linux OS Version: 2.6.32-358.el6.x86_64 Architecture: amd64 JVM Version: 1.8.0_45-b14 JVM Vendor: Oracle Corporation [root@nod2 local]# vim /etc/profile.d/tomcat.sh CATALINA_HOME=/usr/local/tomcat PATH=$CATALINA_HOME/bin:$PATH export CATALINA_HOME PATH [root@nod2 local]# source /etc/profile.d/tomcat.sh
为tomcat提供一个启用脚本:
[root@nod2 ~]# vim /etc/rc.d/init.d/tomcat #!/bin/sh #Description: This shell script manage apache tomcat. #Author: zhaochj #Time: 2015-5-18 #Version: 1.0 case $1 in "start") /usr/local/tomcat/bin/catalina.sh start ;; "stop") /usr/local/tomcat/bin/catalina.sh stop ;; "restart") /usr/local/tomcat/bin/catalina.sh stop sleep 3 /usr/local/tomcat/bin/catalina.sh start ;; *) echo "Usage:`basename $0` {start|stop|restart}" exit 1 ;; esac [root@nod2 ~]# chmod +x /etc/rc.d/init.d/tomcat
在nod3上以同样的方法安装jdk与tomcat。
两个节点都启动tomcat,测试一下能否进入默认界面,经测试,两个节点都能进入tomcat的默认界面,但在catalina.out日志输出中发现有如下提示:
[root@nod2 tomcat]# tail /usr/local/tomcat/logs/catalina.out ...... INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib ....
这是因为tomcat可以整合本地的apr,使用tomcat处理静态资源时性能更好,要想启用tomcat的此功能,进行如下配置:
[root@nod2 bin]# pwd /usr/local/tomcat/bin [root@nod2 bin]# tar xf tomcat-native.tar.gz [root@nod2 bin]# cd tomcat-native-1.1.33-src/jni/native/ [root@nod2 native]# ./configure --with-apr=/usr/bin/apr-1-config --with-java-home=/usr/java/jdk1.8.0_45 [root@nod2 native]# make && make install [root@nod2 native]# ls /usr/local/apr/lib/ libtcnative-1.a libtcnative-1.la libtcnative-1.so libtcnative-1.so.0 libtcnative-1.so.0.1.33 pkgconfig [root@nod2 native]# cp /usr/local/apr/lib/libtcnative-1.so /usr/lib64/
重启tomcat,再观察输出日志中有
INFO: Loaded APR based Apache Tomcat Native library 1.1.33 using APR version 1.3.9.
May 18, 2015 5:03:00 PM org.apache.catalina.core.AprLifecycleListener lifecycleEvent
INFO: APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true]
则证明apr的问题已解决。
接着创建虚拟主机及增加jvmRoute:
[root@nod2 tomcat]# vim /usr/local/tomcat/conf/server.xml 把<Engine name="Catalina" defaultHost="localhost">修改成<Engine name="Catalina" defaultHost="localhost" jvmRoute="tomcat1"> 在“nod3”上把<Engine name="Catalina" defaultHost="localhost">修改成<Engine name="Catalina" defaultHost="localhost" jvmRoute="tomcat2"> 在<Engine>容器中增加一个<Host>容器,内容如下: <Engine> ..... <Host name="nod2.test.com" appBase="/tomcat/app" unpackWARs="true" autoDeploy="true"> <Context path="" docBase="mysite"/> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="nod2_access_log." suffix=".txt" pattern="%h %l %u %t "%r" %s %b" /> </Host> ...... </Engine>
在"nod3"上增加以下内容:
<Engine> ..... <Host name="nod3.test.com" appBase="/tomcat/app" unpackWARs="true" autoDeploy="true"> <Context path="" docBase="mysite"/> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="nod3_access_log." suffix=".txt" pattern="%h %l %u %t "%r" %s %b" /> </Host> ...... </Engine>
接下来为tomcat提供一个工程(nod2与nod3上创建过程一样):
#创建一个工程目录mysite [root@nod2 ~]# mkdir -pv /tomcat/app/mysite [root@nod2 ~]# cp -r /usr/local/tomcat/webapps/host-manager/WEB-INF/ /tomcat/app/mysite [root@nod2 ~]# vim /tomcat/app/mysite/index.jsp #一个测试所用的工程,nod3上把此文件中的“nod2”修改为“nod3” <%@ page language="java" %> <html> <head><title>nod2</title></head> <body> <h1><font color="red">nod2</h1> <table align="centre" border="1"> <tr> <td>Session ID</td> <% session.setAttribute("abc","abc"); %> <td><%= session.getId() %></td> </tr> <tr> <td>Created on</td> <td><%= session.getCreationTime() %></td> </tr> </table> </body> </html> 两个节点都配置好后,启动tomcat,测试: [root@nod2 ~]# service tomcat start [root@nod3 ~]# service tomcat start
3.3、MSM sticky session + kryo模式的配置
在进行配置之前,把MSM和序列化需要的包准备好。
[root@nod2 msm]# pwd /root/software/msm [root@nod2 msm]# ls msm_kryo_serializers/ asm-3.2.jar memcached-session-manager-1.8.3.jar msm-kryo-serializer-1.8.3.jar kryo-1.04.jar memcached-session-manager-tc7-1.8.3.jar reflectasm-1.01.jar kryo-serializers-0.11.jar minlog-1.2.jar spymemcached-2.11.1.jar
把上边的所有jar包放在$CATALINA_HOME/lib目录内:
[root@nod2 msm]# cp msm_kryo_serializers/* /usr/local/tomcat/lib/
接着更新<Context>元素,建议最好不要在$CATALINA_HOME/conf/server.xml定义,这样太具有侵略性,对整个tomcat都有效。应配置$CATALINA_HOME/conf/context.xml文件。
在配置tomcat相关的配置文件时,应该先停止tomcat服务,再做修改。
把以下代码加入到context.xml中,两个节点都要进行修改:
<Context> ..... <Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager" memcachedNodes="memcached1:192.168.0.201:11211,memcached2:192.168.0.202:11211" failoverNodes="memcached1" requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$" transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"/> ..... </Context>
failoverNodes="memcached1"告诉MSM把session信息优先存放在memcached2中,只有当memcached2不可用时,才把session存放在memcached1中,memcached1是一个失效转移的节点。
在nod2上设置failoverNodes="memcached1",在nod3上设置failoverNodes="memcached2",这不是必须,我只是用来验证两个节点到底是把session优先存放在哪个memcached上。
文件修改好后,启动tomcat服务,分别访问两个节点进行测试:
看上边两个节点的seesion的返回信息,nod2把session存放在了memcached2上,此节点上的failoverNodes="memcached1";nod3上刚是把session存放在memcached1上,它的failoverNodes="memcached2"。
现在我把nod2上的memcached关闭,再来看下两个节点的返回信息。
[root@nod2 webapps]# service memcached stop Stopping memcached: [ OK ]
nod3把session的存放节点重定向到了memcached2上了,我再启动nod2上的memcached服务,nod3页面不会自动再定向回memcached1,我再关闭nod2上的memcached服务,访问我们的两个站点,Session ID中的memcached1或memcached2都能正常的切换,切换后前边的session id也是保持不变的,说明用户的session信息真正的保存在了memcached服务器上。
3.4、MSM no-sticky session + kryo模式的配置
基于no-sticky seesion + kryo的模式,只需要把要增加在context.xml的代码更换成下边的即可
<Context> .... <Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager" memcachedNodes="memcached1:192.168.0.201:11211,memcached2:192.168.0.202:11211" sticky="false" sessionBackupAsync="false" lockingMode="uriPattern:/path1|/path2" requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$" transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"/> ...... </Context>
经测试,在no-sticky session模式下,后端的memcached各节点没有主、备之分,完全由MSM自行决定使用哪个memecached节点,用户的session信息由MSM写入到各个memcached中,只要有一个memcached节点正常工作,那用户的session信息就不会丢失。
4、思考与总结
至此,此博文介绍完了利用MSM来构建一套可伸缩的高可用session共享集群,此博文是参考了官方文档和网络上的资料,再加上不断的摸索搭建出来的,在做环境测试时有个细节值得注意,起初在启用、停止tomcat服务时,我没有在意日志的输出,只是查看监听的端口是否在监听“8080”端口,而且访问也是正常的,但当我不经意去查看日志输出时,发现日志给予我们好多细节,且还有些错误,当一些错误发生时,tomcat还能正常的访问,如果是在生产环境下会有隐患的,所以在搭建环境,调度程序时,在程序的启动、停止时都要不断的监视日志输出信息,确保环境搭建好后,日志中不会有错误信息,如果有警告也要仔细分析,此信息的产生由来,是否会带来隐患等。
这次环境搭建好后,在关闭tomcat时,日志输出中还有以下的信息:
SEVERE: The web application [/docs] appears to have started a thread named [Memcached IO over {MemcachedConnection to /192.168.0.202:11211 /192.168.0.201:11211} - SHUTTING DOWN (informed client)] but has failed to stop it. This is very likely to create a memory leak.
通过google也没有得到什么解决方案,只是说这个警告信息不是什么应用程序所报的信息,但最好还是不要有。(此问题的相关信息在这里https://code.google.com/p/memcached-session-manager/issues/detail?id=197)
转载于:https://blog.51cto.com/zhaochj/1652598