使用Session共享也分两种机制，两种情况如下：
① 粘性session处理方式
原理：不同的 tomcat指定访问不同的主memcached。多个Memcached之间信息是同步的，能主从备份和高可用。用户访问时首先在tomcat中创建session，然后将session复制一份放到它对应的memcahed上。memcache只起备份作用，读写都在tomcat上。当某一个tomcat挂掉后，集群将用户的访问定位到备tomcat上，然后根据cookie中存储的SessionId找session，找不到时，再去相应的memcached上去session，找到之后将其复制到备tomcat上。
② 非粘性session处理方式
原理：memcached做主从复制，写入session都往从memcached服务上写，读取都从主memcached读取，tomcat本身不存储session
优点：可容错，session实时响应。
实现方式：用开源的msm插件解决tomcat之间的session共享：Memcached_Session_Manager（MSM）
a. 复制相关jar包到tomcat/lib 目录下
JAVA memcached客户端：spymemcached.jarmsm项目相关的jar包：1. 核心包，memcached-session-manager-{version}.jar2. Tomcat版本对应的jar包：memcached-session-manager-tc{tomcat-version}-{version}.jar序列化工具包：可选kryo，javolution,xstream等，不设置时使用jdk默认序列化。b. 配置Context.xml ，加入处理Session的Manager
粘性模式配置：
非粘性配置：
第四种：session持久化到数据库
原理：就不用多说了吧，拿出一个数据库，专门用来存储session信息。保证session的持久化。
优点：服务器出现问题，session不会丢失
缺点：如果网站的访问量很大，把session存储到数据库中，会对数据库造成很大压力，还需要增加额外的开销维护数据库。
第五种terracotta实现session复制
原理：Terracotta的基本原理是对于集群间共享的数据，当在一个节点发生变化的时候，Terracotta只把变化的部分发送给Terracotta服务器，然后由服务器把它转发给真正需要这个数据的节点。可以看成是对第二种方案的优化。
优点：这样对网络的压力就非常小，各个节点也不必浪费CPU时间和内存进行大量的序列化操作。把这种集群间数据共享的机制应用在session同步上，既避免了对数据库的依赖，又能达到负载均衡和灾难恢复的效果。
