网上有很多关于通过MSM(memcached session manager)实现memcached共享session的文章,但是很多都是东拼西凑,误导别人。正巧最近有一个地方用到,特此总结一下。

    MSM支持tomcat6,tomcat7,tomcat8,MSM支持两种模式:sticky sessions(粘性session)和non-sticky sessions(非粘性session)。我用到的是sticky session,所以以下都按照sticky session

来介绍。集群结构是2个tomcat实例节点,2个memcached实例节点

    <tomcat1>   <tomcat2>
           . \ / .
  machine1 .  X  . machine2
           . / \ .
<memcached1>   <memcached2>

简单说明下:tomcat1为主要把它的session存储到memcached2上,而memcache2是运行在另一台主机上的(一般情况下,memcached是存tomcat1的session),只有当memcached2不可用时,tomcat1才会把session存在memcached1上,也就是说memcached1是为了tomcat1做故障切换用的节点。这要的话,当machine1挂了的时候,session是不会丢失的。


接着我们考虑使用session的哪种序列化方式,默认的是使用java进行序列化,是由memcached-session-manager.jar这个jar包来提供的方法,而其它的序列化方式是由其它的jar包提供的。


首先是要安装jdk和tomcat,这里不再赘述,当然tomcat可以选择支持native函数。在修改tomcat配置文件之前,先把一些jar包放在 $CATALINA_HOME/lib/( WEB-INF/lib)目录里,再修改$CATALINA_HOME/conf/ (META-INF/context.xml)配置文件。


我们使用的是memcached,所以需要 spymemcached-2.11.1.jar

补充:如果使用couchbase,需要添加以下jar包: couchbase-client-1.4.0.jar jettison-1.3.jarcommons-codec-1.5.jarhttpcore-4.3.jar,httpcore-nio-4.3.jarnetty-3.5.5.Final.jar


需要注意的是,如果你使用java内置的序列化方式,把jar放在$CATALINA_HOME/lib/里即可。如果为了更好的性能,使用自定义的序列化方式,就要把其它jar包部署在具体java项目工程下的WEB-INF/lib里。以下是四种session序列化方式对应需要的jar包


  • kryo-serializer: msm-kryo-serializer, kryo-serializers-0.11 (0.11 is needed, as 0.20+ is for kryo2), kryo, minlog, reflectasm, asm-3.2

  • javolution-serializer: msm-javolution-serializer, javolution-5.4.3.1

  • xstream-serializer: msm-xstream-serializer, xstream, xmlpull, xpp3_min

  • flexjson-serializer: msm-flexjson-serializer, flexjson


所以非粘性sessions 使用kryo序列化所需要增加的jar包如下:

wKiom1RHEauzhcQnAAC2YW9b-dM187.jpg


虽然我使用的是kryo序列化方式 + 非粘性session,但是还是把粘性session一起介绍一下。

 sticky sessions粘性session + kryo序列化

在machine1上有tomcat1和memcached1,tomcat的$CATALINA_HOME/conf/context.xml增加如下配置

<Context>
  ...
  <Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
    memcachedNodes="n1:host1.example.com:11211,n2:host2.example.com:11211"
    failoverNodes="n1"
    requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$"
    transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"
    />
</Context>


参数failoverNodes="n1" 是用来告诉 MSM 把session优先存储在 memcached2上,只有当memcached2挂了的时候才会把session存在memcache1也就是配置文件的n1里。

假如整个machine1挂了,session还是可用,因为session是存在machine2的memcache2上,可以通过tomcat2对外提供服务。

machine2上的tomcat2的配置文件只要改成failoverNodes="n2"即可。


 non-sticky sessions 非粘性session + kryo序列化

非粘性session是不需要配置failoverNodes,也就是故障切换节点的,因此session是由所有tomcat节点通过轮训(round-robin )来提供服务的,session是不和某单个tomcat节点绑定,所以tomcat所有节点的都是一样的,如下:

<Context>
  ...
  <Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
    memcachedNodes="n1:host1.example.com:11211,n2:host2.example.com: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>

配置完成后重新启动两个节点上的不同tomcat服务。

tail -f /usr/local/tomcat/logs/catalina.out

wKiom1RGYIKACNTdAAo-3_MzksQ616.jpg

两个节点tomcat的启动日志都正常。


测试的session.jsp页面内容如下

SessionID:<%=session.getId()%> <BR>
SessionIP:<%=request.getServerName()%> <BR>
SessionPort:<%=request.getServerPort()%>

浏览器访问测试页面

wKiom1RGaHSy14-BAALVRBJmvwE682.jpg

页面获取的和我chrome浏览器截获的cookie里session id是一样的,这里补充下session id是保存在cookie里的。

多次刷新页面session.jsp,发现session id不变化,再查看访问tomcat的访问日志,出现多条访问记录(这里补充说明,tomcat默认是关闭访问日志的,需要开启,然后自定义日志格式。)但是session保持不变。

wKioL1RGZcCTUVAqAAU_FvVswHg499.jpg

由于session默认是存在tomcat的jvm里的,我们验证一下memcached里是不是真的存了这个session记录,查询memcached存的内容然后导出到文件里

 echo "stats cachedump 3 0" | nc 192.168.203.167 11211 > session.txt
 grep '6EDE9D610F85926D0A5AD01A991DC84C-n1 ' session.txt

wKioL1RGZ8-QnpF9AACI_MweLhM965.jpg

确认存在。

至此tomcat的MSM,共享session的工作就做完了,good luck!