Session共享有多种解决方法，常用的有四种：
1）客户端Cookie保存
2）服务器间Session同步
3）使用集群管理Session（如MSM）
4）把Session持久化到数据库
针对上面Session共享四种方法的详解：
1）客户端Cookie保存以cookie加密的方式保存在客户端.优点是减轻服务器端的压力，每次session信息被写在客服端,然后经浏览器再次提交到服务器。即使两次请求在集群中的两台服务器上完成，也可以到达session共享。
2）将session持久化到数据中这种共享session的方式即将session信息存入数据库中，其它应用可以从数据库中查出session信息。目前采用这种方案时所使用的数据库一般为mysql。 利用数据库共享 session 的方案有一定的实用性，但也有如下缺点：首先 session 的并发读写在数据库中完成，对 mysql 的性能要求比较高；其次，我们需要额外地实现 session 淘汰(超时)逻辑代码，即定时从数据库表中更新和删除 session 信息，增加了工作量。
3）使用服务器间session同步使用主-从服务器的架构，当用户在主服务器上登录后，通过脚本或者守护进程的方式，将session信息传递到各个从服务器中，这样用户访问其它的从服务器时，就可以读到session信息。 缺点：比如速度慢、不稳定等，另外，如果 session 信息传递是主->从单向的，会有一些风险，比如主服务器down了，其它服务器无法获得 session 信息
4）使用集群统一管理Session提供一个集群保存session共享信息.其他应用统统把自己的session信息存放到session集群服务器组。当应用系统需要session信息的时候直接到 session 集群服务器上读取。目前大多都是使用 Memcache 来对 Session 进行存储。
以Memcache来实现Session共享的方式目前比较流行的有两种实现方案：
a）使用Filter方式：此方式使用过滤器的方式重新对httpRequest 对象进行了包装，并加入memcached客户端,此方式的优点是：使用简单，把过滤器配置进去即可，另外比较灵活，因为它是在客户端实现的，配置比较灵活,而且服务器无关，你可以在任何支持servlet的容器上部署。
b）使用Memcached-Session-Manager，俗称MSM，是一个用于解决分布式 tomcat 环境下 session 共享的问题的开源解决方案。它的实现原理为以tomcat插件的方式部署在服务器，修改了 servlet 容器代码中的 session 相关代码，使其连接 memcached ，在 memcached 中创建和更新session。
MSM为什么要产生？
通常来说，对于一些大型的web2.0的网站，在正式部署时一般是部署在不同故障域的多台应用服务器上，以j2ee应用为例，一般都会部署在tomcat下。假如部署了10台tomcat服务器，那这10台tomcat可能是部署在不同的机器上，然后将应用程序copy到这10台tomcat下，然后启动所有tomcat。一般来说这样做的目的是为了达到负载均衡以及避免单点故障，另外也考虑到国内网络环境的原因，避免跨网络运营商访问而导致访问速度低下的问题，当然不要忘了坐镇这10台tomcat前端的还有我们的反向代理服务器。比如nginx，这个就是另一个话题了，下面主要讲的是，对于这种分布式tomcat环境，如何保证session 的唯一性？？
一般来说，大体的解决方案是通过编写一段代码或者通过配置tomcat的filter，将产生的session放到同一个内存数据库中，事实上这确实可行的。然而这种问题应该有更省事更成熟的解决方案，也就是将要说的Memcached_Session_Manager，简称msm，这就是一个用于解决分布式tomcat环境下session共享的问题的开源解决方案。
MSM（即memcached session manager）是一个高可用Tomcat session共享解决方案，除了可以从本机内存快速读取Session信息(仅针对黏性Session)外，还可使用memcached存取Session，以实现高可用。
对于非黏性Session，memcached直接存储session。除memcached外，还可以其他缓存组件如memcachedb, membase等。
MSM特性：
. 支持黏性、非黏性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及以后版本已经支持。
--------------------------------------------------------------------------------------------------------------------------------------------
黏性Session和非粘性Session，一般用于tomcat服务集群，二者的区别是：
1）黏性Session（即sessionsticky，不复制Session会话）：
此模式下同一会话中的请求都被派送到同一个tomcat实例上，这样就无须在多台服务器之间实现session共享了，这是其好处。
不好的地方就是不能实现failureover（故障切换）了，一但用户访问的机器挂掉，那么其session就会丢失。
也就是说当用户发出第一个request后，负载均衡器动态的把该用户分配到某个节点，并记录该节点的路由，以后该用户的所有request都绑定到这个路由，
用户只会与该server发生交互，这种策略被称为粘性session。
这种方式将同一用户的请求转发到特定的Tomcat服务器上，避免了集群中Session的复制，缺点是用户只跟一种的一台服务器通信，如果此服务器down掉，那就废了。
2）非黏性Session（即sessionreplication，复制Session会话）此模式下同一会话中的请求可以被分配到不同的tomcat实例上进行处理，此时就需要在不
同服务器之间同步、复制session，这样一来即使一台服务器挂掉了，请求在其它服务器上照样可以访问到session信息，其缺
点在于Session复制需要系统资源和网络开销。
-------------------------------------------------------------------------------------------------------------------------------------------------
MSM如何工作？
首先谈下tomcat故障转移
msm安装在tomcat里，tomcat会在本地保留所有会话信息就像StandardManager一样。此外，一个请求完成后，session会被备份到memcached节点。 当服务同一会话的下一次请求时，tomcat可以在本地找到这个会话数据，同一会话的第二次请求 处理完后，会话数据会更新到memcached节点。 假设处理某个会话的tomcat挂了。 那么下次请求会被路由到另一个tomcat。而这个tomcat没有在本地保存该会话的数据。因此它会去相应的memcached（根据请求头中sessionid的后缀，后面配置$CATALINA_HOME/conf/context.xml时，memcachedNodes="n1:localhost:11211,n2:localhost:11212"，就是n1,n2）中查找此次请求的会话数据并保存到本地。 这样这个tomcat就可以处理此次会话了。当这个tomcat处理完此次会话，它会将更新相应memcached节点存储的session信息。
如下图tomcat1故障，路由到tomcat2由负载均衡完成(如nginx)。
再说下memcahced故障转移
msm也实现了memcached的故障转移。当一个memcached节点不可用时，session信息就会被转移到其他memcached节点。 与此同时，sessionid会被修改，一个新的JESESSIONID(响应头会有Set-Cookie:JESSIONID;XXXXXXXXXXXXX)会被发送 到浏览器端。当使用粘性session（sticky session）时，确保你的负载均衡不会给sessionid添加后缀。
SESSIONID的格式
MSM知道Memcached节点列表，这些节点标识会存储在SESSIONID中，SESSIONID值类似：602F7397FBE4D9932E59A9D0E52FE178-n1 【其中n1为Memcached节点标识】
MSM原理
MSM利用Value（Tomcat 阀）对Request进行跟踪。Request请求到来时，从memcached加载session，Request请求结束时，将tomcat session更新至memcached，以达到session共享之目的，支持sticky（粘性）和non-sticky（非粘性）模式。需要注意的是使用sticky模式时需要配置jvmroute参数，配置方式如下：
配置$CATALINA_HOME/conf/server.xml
<Engine name="Catalina"defaultHost="localhost"jvmRoute="tomcat2">
注意每台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为主session，memcached2为备session。Request请求到来时，从memcached2加载备session到tomcat，（当容器中还是没有session，则从memcached1加载主session到tomcat，这种情况是只有一个memcached节点，或者有memcached1出错时），Request请求结束时，将tomcat session更新至主memcached1和备memcached2，并且清除tomcat session，以达到主备同步之目的。
如下是non-sticky模式的响应流程图：