我 们都知道对于一些大型的web2.0的网站，在正式部署时一般是部署在不同故障域的多台应用服务器上，以j2ee应用为例，一般我们都会部署在 tomcat下，假如我们部署了10台tomcat服务器，那这10台tomcat可能是部署在不同的机器上，然后将应用程序copy到这10台 tomcat下，然后启动所有tomcat，一般来说这样做的目的是为了达到负载均衡以及避免单点故障，另外也考虑到国内网络环境的原因，避免跨网络运营 商访问而导致访问速度低下的问题，当然不要忘了坐镇这10台tomcat前端的还有我们的反向代理服务器，比如nginx，这个就是另一个话题了，我今天 主要讲的是，对于这种分布式tomcat环境，我们如何保证session 的唯一性（我假定你知道session是什么）。这也是在日期公司的一个项目中负责解决的一个问题，当然实际上这并不是什么新的议题，之前就有很多解决方 案，但是一般来说的大体的解决方案是自己通过编写一段代码或者通过配置tomcat的filter，将产生的session放到同一个内存数据库中，事实 上这确实可行的，只不过我比较懒，我总是觉得这种问题应该有更省事更成熟的解决方案，那确实是有的，也就是我马上介绍 的 Memcached_Session_Manager，简称msm，这就是一个用于解决分布式tomcat环境下session共享的问题的开源解决 方案。

一 简介

（以下内容由个人根据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都需要）

2. 修改每台tomcat的conf目录下得context.xml文件或者server.xml文件，在其中加入如下任意一段代码（注意：当使用多台tomcat时，一定要使用non-sticky模式）：

A：使用默认的sticky session，kryo序列化方式，memcached缓存

B：使用non-sticky session

C：使用membase

当使用javolution序列化方式时将：

替换为：

配置完成后，分别启动tomcat，正常启动说明msm配置成功。

3. 最后附上nginx配置：

修改配置文件nginx\conf\nginx.conf

1. 找到内容server {

在它的上面加入如下内容：

2. 找到

把内容更改如下：

3.  找到

把内容改成如下：

(这是监听访问域名绑定那台服务器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

注意每台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模式的响应流程图：（图片来源网络）。

Memcached一些特性和限制

l 在 Memcached 中可以保存的 item 数据量是没有限制的，只有内存足够

l Memcached 单进程最大使用内存为 2G ，要使用更多内存，可以分多个端口开启多个 ， Memcached进程

l 最大 30 天的数据过期时间 , 设置为永久的也会在这个时间过期，常量 REALTIME_MAXDELTA 60 * 60 *24 *30控制

l 最大键长为 250 字节，大于该长度无法存储，常量 KEY_MAX_LENGTH 250 控制

l 单个 item最大数据是1MB ，超过1MB 数据不予存储，常量 POWER_BLOCK 1048576 进行控制，它是默认的 slab大小

l 最大同时连接数是200 ，通过conn_init() 中的freetotal 进行控制，最大软连接数是 1024，通过settings.maxconns=1024进行控制

l 跟空间占用相关的参数： settings.factor=1.25, settings.chunk_size=48, 影响 slab的数据占用和步进方式

关于Memcached的使用，应当在需要的情况下才使用Memcached，比如需要实现分布式缓存系统，否则，如果是类似单台缓存服务器，那么建议最好不要用Memcached，改用其他缓存系统。