官方网站：http://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration
当用户数量和集群数量达到一定规模后，Session 复制就可能成为性能瓶颈。于是人们提出了 从第三方缓存恢复失效节点数据的方案，开源产品 Memcached-Session-Manager（下面简称MSM）就是基于这个思想。
MSM是一个高可用的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及以后版本已经支持。
三、Sticky Session 模式下的工作原理
Tomcat 的本地 session 为主 session，Memcached 中的 session 为备 session。
第一步，所有 Tomcat 节点都需要安装 MSM；每一个 Tomcat 会有自己的本地 session。
第二步，当一个请求执行完毕之后，如果对应的 session 在本地不存在（即这是某一个用户的第一次请求），则将该 session 复制一份至 Memcached。
第三步，当该 session 的下一个请求到达时，会使用 Tomcat 的本地 session。请求处理结束之后，session 的变化会同步更新到 Memcached，保证数据一致。
第四步，如果当前 Tomcat 节点失效，下一个请求会被路由给其他 Tomcat。这个 Tomcat 发现请求所对应的 session 并不存在，于是它将查询 Memcached，如果查询到了，则恢复将其保存到本地session。此次请求结束，如果session被修改，送回Memcached备份。
这样就完成了容错处理。
四、Non-sticky Session 模式下的工作原理
Tomcat 的本地session为中转session，memcache1 为主 session，memcache2为备 session。
第一步，收到请求，加载备 session 到本地容器；
备 session 加载失败，则从主 session 加载；
第二步，请求处理结束之后，session 的变化会同步更新到 memcache1和 memcache2，并清除Tomcat 的本地 session 。
session data 要想存入 memcache，必须能序列化和反序列化。
上边介绍的是处理Tomcat故障转移，MSM又是如何处理Memcached故障转移呢？
如果一个Memcached故障，当前Memcached中的Session会转移到其他Memcached节点，同时，JSESSIONID被修改并送回浏览器。
如果使用黏性Session，应确保loadbalancer中配置生成的JSESSIONID无任何后缀。
SESSIONID的格式
MSM知道Memcached节点列表，这些节点标识会存储在SESSIONID中，SESSIONID值类似：602F7397FBE4D9932E59A9D0E52FE178-n1 【其中n1为Memcached节点标识】