tomcat集群扩张session集中管理，Memcached-session-manager使用_软件架构设计大全_优良自学吧 |
当前位置： >
> tomcat集群扩张session集中管理，Memcached-session-manager使用优良自学吧提供tomcat集群扩张session集中管理，Memcached-session-manager使用,tomcat集群扩展session集中管理，Memcached-session-manager使用 在研究tomcat做负载均衡的时候如何实现ha，还有就是不采用session复制的方法做集群。想到的是将session全部存储在后端的缓存服务器中。正tomcat集群扩展session集中管理，Memcached-session-manager使用
在研究tomcat做负载均衡的时候如何实现ha，还有就是不采用session复制的方法做集群。想到的是将session全部存储在后端的缓存服务器中。正好网上有这么一个工具Memcached-session-manager（后面简称msm），所以直接扒下来用了。地址如下：/p/memcached-session-manager/msm支持 stickty（沾粘会话）和non-sticky（非沾粘会话）两种集群方式。sticky就是前端的loadbanlence能保证每个用户的请求都路由到了同一个tomcat上。non-sticky则每一次请求都可能路由到了不同的tomcat中。至于msm在这两种方式是怎么处理的看下图：下图来自javaeye的xxtianxiaxing的博客，我这里引用一下，原文地址为/blog/12697041. sticky2. non-sticky用msm的session管理manager替代tomcat自身的standardManager。可以配置在虚拟服务器的context标签中，也可以在context.xml里面全局配置。&!--sticky
&Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
memcachedNodes="n1:localhost:11211"
requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$"
transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"
copyCollectionsForSerialization="false"&!--下面这个是可选的，自己定义特殊的类注册到kryo自定义转换器中，实现序列化--&customConverter="com.test.serializer.CustomKryoRegistration"
&!--non sticky
&Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
memcachedNodes="n1:localhost:11211"
sticky="false"
sessionBackupAsync="false"
lockingMode="auto"
requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$"
transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"
/&上面采用的序列化方式是kryo，根据官方提供的数据，这个的序列化效率是最好的，我下面有一些简单的测试。感觉kryo的效率主要体现在高并发下面。如果非高并发感觉跟java的自带io差不多。如果不使用kryo进行序列化，采用java默认方式的话，请将transcoderFactoryClass改为：de.javakaffee.web.msm.JavaSerializationTranscoderFactory另外在使用kryo进行序列话的时候，有时候会报序列话错误。我开始就报ConcrrentHashMap这个类不能序列化的错误。tomcat在的session的Atrribute使用了这个数据结构来保存。要解决这个问题，需要自己写一个类，将这些特殊的类注册进去。然后打个jar包放tomcat的lib下。就ok了。下面是例子：package com.test. import java.util.concurrent.ConcurrentHashM import com.esotericsoftware.kryo.K import com.esotericsoftware.kryo.serialize.MapS import de.javakaffee.web.msm.serializer.kryo.KryoC public class CustomKryoRegistration implements KryoCustomization { public void customize(Kryo kryo) { kryo.register(ConcurrentHashMap.class, new MapSerializer(kryo)); } } 把这个类打好jar包放tomcat的lib目录下。然后还需要在context中配置customConverter="com.test.serializer.CustomKryoRegistration"，这样就OK了。另外集成kryo序列化的环境需要以下jar包。刚开始googleCode的官方网站上没写。搞了半天，后来提醒原作者加上了：kryo-serializer: msm-kryo-serializer, kryo-serializers, kryo, minlog, reflectasm, asm-3.2其他序列化方式（java自带的序列化方式外的3方序列化方式）需要的jar：javolution-serializer: msm-javolution-serializer, javolution-5.4.3.1xstream-serializer: msm-xstream-serializer, xstream, xmlpull, xpp3_minflexjson-serializer: msm-flexjson-serializer, flexjson可以查看官方网站的文档：/p/memcached-session-manager/wiki/SetupAndConfiguration搭建好所有环境之后，采用1 nginx(ip_hash)+2 tomcat6.0.35+sticky(最好用6.0.2以上版本，因为新的msm包里面使用了6.0.2才有的新方法，不然会报NoSuchMethod-changeSessionId()的错误)验证是否成功：登录发布的系统（发现这个时候请求全部路由到tomcat1），之后，关闭tomcat1，继续在里面做有关session的操作。发现这个时候请求被tomcat2接管，而且session依然保持(从memcached中拿出)。ok，这样就说明成功了。non_sticky的配置一样按上面的方法来验证是否成功。*********最后是我在搭建好msm环境后做的一些简单测试：***************测试环境：TG cpu,内存2G小本本，win7系统。tomcat，memcache全部装win7上。启动一个memcahed服务给了32m内存。tmcat52m内存。ok，首先是前面没有负载均衡，单个tomcat的情况，请求一个sevlet链接，链接就是从session取个值出来的操作。用apache ab，-C 参数带上cookie参数模拟有session的请求，100人，共5000次请求是下面的结果：不用msm: 1000req/smsm-sticky kryo: 850req/smsm-sticky java标准序列化: 830req/smsm-nonsticky kryo : 440/s(50人并发) 430/s(100人并发)msm-nosticky java标准序列化 : 480/s(50人并发) 270/s(100人并发)在sticky的情况下，因为在本地有session的情况下，省略了从memcached取session缓存的情况，序列化次数不多，因此性能只有大概1/10的损耗。在non-stikcy的情况下，集中的每次从memcached取session，性能损失了大概一半。而可以看出，在高并发的情况下，kryo序列化比java标准序列化要好。并发性能大概在java标准序列化一倍以上。而且在搞并发的non-sticky的情况下，session中的多线程并行操作冲突严重。lock很多(当然这个lock模式可以设置，甚至可以完全不要锁)。这也严重降低了速度。又测试了1台nginx(ip_hash做负载均衡)+2tomcat的情况。因为暂时没法模拟多ip的请求，所以所有请求都只路由到了tomcat1上。采用kryo序列化的策略依然保持了高并发下处理速度不下降的优势。还是400多r/s，而java标准序列化还是要低一半多。最后推荐采用sticky+kryo的策略来实现msm～！（本文来自互联网，不代表搜站(/)的观点和立场）编辑推荐最近更新503 - Service Not Available
503 - Service Not Available3690人阅读
声明：本篇文章是根据翻译整理，关于memcached-session-manager的介绍，具体参见官网：，也可以参考：
Introduction
如果为了简单使用，你只需要安装一个tomcat（6或者7）和memcached，在生产环境中可能会有多台tomcat服务器以及多台可用的memcached节点，并安装在不同的机器上，我们可以使用黏性session（sticky sessions）或者非黏性session（non-sticky
sessions），memcached-session-manager (msm)&对这两种操作模式都支持。
下面给出一个黏性session模式的设置示例，此实例中安装了2个tomcat以及2个memcached。
Tomcat-1(t1)的首要选择是把session存储在memcached-2 (m2)上（m2是t1的一个普通节点），而m2是运行在另外的一台机器上。只有当m2不可用（宕机或无法访问）时，t1才会把session存储到memcached-1（m1，m1是t1的故障转移节点）上。使用这种配置，即使机器1宕机了session也不会丢失。具体如下图所示：
我们如何设置才能实现呢？
Decide which serialization strategy to use
从1.1版开始，MSM就提供了多种可选的session序列化策略，默认的策略是使用java进行序列化，这种实现已经集成在memcached-session-manager.jar包中了，其它的策略则可以通过不同的jar包来提供实现。在下面的章节中，我们可以了解到每种策略所需要的jar包具体有哪些。
Configure tomcat
关于tomcat的配置主要包括两个方面，首先需要下载所需要的包，放到tomcat安装目录下的lib目录下（严格来说应该是$CATALINA_HOME/lib/）以及我们应用的WEB-INF/lib/&目录下，同时还需要修改$CATALINA_HOME/conf/context.xml文件，并在&Context&元素中添加memcached session管理的配置信息。
Add memcached-session-manager jars to tomcat
不管你选择哪种序列化策略，你都需要&&，如果你使用的是tomcat6，则还需要下载&&，如果使用的是tomcat7则下载&&。同时还需要下载&.下载这完这些jar包后把jar包放到&$CATALINA_HOME/lib/目录。
Add custom serializers to your webapp (optional)
如果只是使用java序列化的话，那么需要的jar包就是以上所列出的那些了，但是如果想使用自定义的序列化策略（通常性能会更佳），我们还需要下载相应的jar包并放到我们webapp下的WEB-INF/lib/目录中。
如果你的应用使用了maven来进行jar包管理，那么你只需要在pom.xml中加入相应的序列化策略依赖定义就可以了，具体的maven依赖定义如下（任选一种就oK了）：
kryo-serializer：
&&&&&&de.javakaffee.msm&&&&&&msm-kryo-serializer&&&&&&1.6.0&&&&&&runtime&&&&
javolution:
&&&&&&de.javakaffee.msm&&&&&&msm-javolution-serializer&&&&&&1.6.0&&&&&&runtime&&&&
&&&&&&de.javakaffee.msm&&&&&&msm-xstream-serializer&&&&&&1.6.0&&&&&&runtime&&&&
&&&&&&de.javakaffee.msm&&&&&&msm-flexjson-serializer&&&&&&1.6.0&&&&&&runtime&&&&
如果我们不是使用maven仓库来对依赖进行管理的话 ，我们需要针对每种策略下载单独需要的jar包，具体如下：
kryo-serializer:&,&,&,&,&,&javolution-serializer:&,&xstream-serializer:&,&,&,&flexjson-serializer:&,&
Configure memcached-session-manager as&&Context&&Manager
处理完jar包之后，我们还需要修改&$CATALINA_HOME/conf/context.xml文件中Context节点下的内容，添加memcached-session-manager配置。
下面将会讲解关于tomcat配置的具体的示例，主要包括使用memcached来管理黏性session和非黏性session以及使用membase来管理非黏性session。示例基于的前提是假设我们有2个memcached实例，一个运行在host1主机，另一个运行在host2主机，示例使用的序列化方式为kryo。
下面我们给出tomcat1的配置，假设tomcat1和memcached节点n1都是运行在host1主机上，其中属性failoverNodes=&n1&的作用是告诉msm最好是把session保存在memcached
&n2&节点上，只有在n2节点不可用的情况下才把session保存在n1节点。这样即使host1主机宕机，仍然可以通过host2上的tomcat2访问存放在memcached &n2&&节点中的session。
tomcat1 configuration：
&&&&...&&&&&className=&de.javakaffee.web.msm.MemcachedBackupSessionManager&&&&&&&memcachedNodes=&n1::1211&&&&&&&failoverNodes=&n1&&&&&&&requestUriIgnorePattern=&.*\.(ico|png|gif|jpg|css|js)$&&&&&&&transcoderFactoryClass=&de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory&&&&&&&&&&&
以上就是tomcat1的配置信息，对于tomcat2，我们只需要修改一下failoverNodes属性的值为&n2& ，这样tomcat2就会优先把session存放到memcached &n1&节点，其余配置信息都一样。
下面演示一个非黏性session管理的配置示例，对于非黏性的session管理，我们不需要配置failoverNodes属性，因为所有sessions在tomcat集群中是循环可见的，并不会绑定到某一个单独的tomcat，对于非黏性session管理，集群中的所有tomcat都是用同一个配置，具体信息如下：
&&&&...&&&&&className=&de.javakaffee.web.msm.MemcachedBackupSessionManager&&&&&&&memcachedNodes=&n1::1211&&&&&&&sticky=&false&&&&&&&sessionBackupAsync=&false&&&&&&&lockingMode=&uriPattern:/path1|/path2&&&&&&&requestUriIgnorePattern=&.*\.(ico|png|gif|jpg|css|js)$&&&&&&&transcoderFactoryClass=&de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory&&&&&&&&&&&
如果是使用membase来对session进行管理，那么则某一个节点的配置如下：
&&&&...&&&&&className=&de.javakaffee.web.msm.MemcachedBackupSessionManager&&&&&&&memcachedNodes=&:8091/pools&&&&&&&username=&bucket1&&&&&&&password=&topsecret&&&&&&&memcachedProtocol=&binary&&&&&&&sticky=&false&&&&&&&sessionBackupAsync=&false&&&&&&&requestUriIgnorePattern=&.*\.(ico|png|gif|jpg|css|js)$&&&&&&&transcoderFactoryClass=&de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory&&&&&&&&&&&
在context.xml中配置完msm之后，&我们就可以启动我们的应用程序了，这样所有的session将会根据系统配置存储到指定的memcached节点或者membase中。
Overview over memcached-session-manager configuration attributes
className&(required)
类名：de.javakaffee.web.msm.MemcachedBackupSessionManager
memcachedNodes&(required)
memcached节点：此属性应该包含所有运行的memcached节点或者membase bucket的uri地址，每一个memcached节点的属性定义格式为&id&:&host&:&port&，多个节点定义直接使用空格或者逗号分隔，形如：memcachedNodes=&n1:app01:11211,n2:app02:11211&，如果只有单个的memcached节点，则&id&是可选项，只需配置&host&:&port&即可，形如：memcachedNodes=&localhost:11211&。
如果我们配置的是membase，那么从1.6.0版本开始，我们可以配置指定一个或者多个membase bucket uris，形如：http://host1:8091/pools,http://host2:8091/pools。Bucket&名称和密码通过属性username,password来定义。membase
buckets连接需要遵循memcached协议，传输数据通过二进制流方式。
failoverNodes&(optional, must not be used for non-sticky sessions)
故障转移节点：可选项，对非黏性session不可用，属性必须包含memcached节点集群的所有ids。节点id之间用空格或者逗号分隔。
username&(since 1.6.0, optional)
从1.6.0版开始使用，并且是可选的。用来进行membase bucket或者SASL验证。
password&(since 1.6.0, optional)
从1.6.0版开始使用，并且是可选的。用来进行membase bucket或者SASL验证，密码可以为空。
memcachedProtocol&(since 1.3, optional, default&text)
定义memcached协议，默认使用text文本
sticky&(since 1.4.0, optional, default&true)
定义session方式为黏性或非黏性，默认为true
lockingMode&(since 1.4.0, optional, for non-sticky sessions only, default&none)
只有非黏性session才使用，默认值为none
none: 从不对session进行锁定all: session将一直被锁定，知道请求结束auto: 对于只读请求，session将不会被锁定，如果是非只读请求，则session会被锁定uriPattern:&regexp&: 通过正则表达式的方式来对请求uri以及查询字符串进行匹配，只有匹配上的才会被锁定。
requestUriIgnorePattern&(optional)
sessionBackupAsync&(optional, default&true)
backupThreadCount&(since 1.3, optional, default&number-of-cpu-cores)
sessionBackupTimeout&(optional, default&100)
operationTimeout&(since 1.6.0, optional, default&1000)
sessionAttributeFilter&(since 1.5.0, optional)
transcoderFactoryClass&(since 1.1, optional, default&de.javakaffee.web.msm.JavaSerializationTranscoderFactory)
序列化接口实现：
Java serialization:&de.javakaffee.web.msm.JavaSerializationTranscoderFactory&based serialization:&de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactoryJavolution based serialization:&de.javakaffee.web.msm.serializer.javolution.JavolutionTranscoderFactoryXStream based serialization:&de.javakaffee.web.msm.serializer.xstream.XStreamTranscoderFactory
copyCollectionsForSerialization&(since 1.1, optional, default&false)
customConverter&(since 1.2, optional)
enableStatistics&(since 1.2, optional, default&true)
enabled&(since 1.4.0, optional, default&true)
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：150784次
积分：2186
积分：2186
排名：第6746名
原创：32篇
转载：228篇
评论：36条
(1)(2)(1)(13)(1)(5)(4)(1)(6)(3)(17)(40)(2)(1)(6)(17)(1)(19)(3)(5)(1)(6)(8)(10)(34)(17)(2)(30)(4)Memcached-session-manager原理 - To Strive To Seek To Find
Not To Yield - ITeye技术网站
博客分类：
我们先看下MSM的流程：
MSM(memcached-session-manager)支持tomcat6和tomcat7，利用Value（Tomcat阀）对Request进行跟踪。Request请求到来时，从memcached加载session，Request请求结束时，将tomcat session更新至memcached，以达到session共享之目的，支持sticky和non-sticky模式。
Sticky模式：
tomcat session为主session，memcached为备session。
Request请求到来时，从memcached加载备session到tomcat (仅当tomcat jvmroute发生变化时，否则直接取tomcat session)；Request请求结束时，将tomcat session更新至memcached，以达到主备同步之目的。
（来源自网络）
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，以达到主备同步之目的。
（来源自网络）
memcached使用LRU算法来处理缓存。但是毛病在于它不是全局的，而是基于slab。 这样你会发现在运行一段时间后，最早访问的那些用户的SESSION会莫名其妙的丢失，即使他们上一秒还有过操作。
请看memcached的内存分配算法
要解决基于 memcache 方案的数据丢失问题，可能解决的方案是：
2、引入持久化存储介质
下载次数: 17
浏览: 290137 次
来自: 北京
经测试，if(batch==500){
[b]发生的方式[/b]
没看到使用threadlocal来实现线程安全，怎么回事？
怪不得，我现在做测试还没有导入证书，单点退出时，虽然casse ...
帮了大忙！感谢楼主！用过memcached-session-manager的进来看下
[问题点数：100分，结帖人kingxir]
用过memcached-session-manager的进来看下
[问题点数：100分，结帖人kingxir]
不显示删除回复
显示所有回复
显示星级回复
显示得分回复
只显示楼主
相关帖子推荐：
本帖子已过去太久远了，不再提供回复功能。