MSM实现tomcat集群中session共享的高可用

目录

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

    简易拓扑如下：

               

                 . \   / .

                  .  X  .

                 . /   \ .

             

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
把修改成
在“nod3”上把修改成
在容器中增加一个容器，内容如下：

.....

            
        
      
......

在"nod3"上增加以下内容：

.....

            
        
      
......

接下来为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" %>

 
 
  
nod2
  
   
    Session ID
  <% session.setAttribute("abc","abc"); %>
    <%= session.getId() %>
   
   
    Created on
    <%= session.getCreationTime() %>
   
  
 

两个节点都配置好后，启动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/

接着更新元素，建议最好不要在$CATALINA_HOME/conf/server.xml定义，这样太具有侵略性，对整个tomcat都有效。应配置$CATALINA_HOME/conf/context.xml文件。

在配置tomcat相关的配置文件时，应该先停止tomcat服务，再做修改。

把以下代码加入到context.xml中，两个节点都要进行修改：

 
.....
 
.....

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的代码更换成下边的即可

....

......

经测试，在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）