如果不做任何处理的话，用户将出现频繁登录的现象，比如集群中存在 A、B 两台服务器，用 户在第一次访问网站时，Nginx 通过其负载均衡机制将用户请求转发到 A 服务器，这时 A 服 务器就会给用户创建一个 Session。当用户第二次发送请求时，Nginx 将其负载均衡到 B 服务 器，而这时候 B 服务器并不存在 Session，所以就会将用户踢到登录页面。这将大大降低用户 体验度，导致用户的流失，这种情况是项目绝不应该出现的。
- 粘性 Session 原理 粘性 Session 是指将用户锁定到某一个服务器上，比如上面说的例子，用户第一次请求 时，负载均衡器将用户的请求转发到了 A 服务器上，如果负载均衡器设置了粘性 Session 的话，那么用户以后的每次请求都会转发到 A 服务器上，相当于把用户和 A 服 务器粘到了一块，这就是粘性 Session 机制。
优点
简单，不需要对 Session 做任何处理。
缺点
缺乏容错性，如果当前访问的服务器发生故障，用户被转移到第二个服务器上时，他的 Session 信息都将失效。
适用场景
发生故障对客户产生的影响较小； 服务器发生故障是低概率事件。
- 服务器 Session 复制
原理
任何一个服务器上的 Session 发生改变，该节点会把这个 Session 的所有内容序列化，然后广 播给所有其它节点，不管其他服务器需不需要 Session，以此来保证 Session 同步。
优点
可容错，各个服务器间 Session 能够实时响应。
缺点
会对网络负荷造成一定压力，如果 Session 量大的话可能会造成网络堵塞，拖慢服务器性能。 实现方式 设置 Tomcat 的 server.xml 开启 tomcat 集群功能。 在应用里增加信息：通知应用当前处于集群环境中，支持分布式，即在 web.xml 中添加 选 项。
- Session 共享机制
使用分布式缓存方案比如 Memcached、Redis，但是要求 Memcached 或 Redis 必须是集群。
使用 Session 共享也分两种机制，两种情况如下：
3.1 粘性 Session 共享机制 和粘性 Session 一样，一个用户的 Session 会绑定到一个 Tomcat 上。Memcached 只是起 到备份作用。
3.2 非粘性 Session 共享机制
原理
Tomcat 本身不存储 Session，而是存入 Memcached 中。Memcached 集群构建主从复制架 构。
优点
可容错，Session 实时响应。 实现方式 用开源的 msm 插件解决 Tomcat 之间的 Session 共享： Memcached_Session_Manager（MSM）
- Session 持久化到数据库
原理
拿出一个数据库，专门用来存储 Session 信息。保证 Session 的持久化。
优点
服务器出现问题，Session 不会丢失。
缺点
如果网站的访问量很大，把 Session 存储到数据库中，会对数据库造成很大压力，还需要增加 额外的开销维护数据库。
- Terracotta 实现 Session 复制
原理
Terracotta 的基本原理是对于集群间共享的数据，当在一个节点发生变化的时候， Terracotta 只把变化的部分发送给 Terracotta 服务器，然后由服务器把它转发给真正需要这 个数据的节点。它是服务器 Session 复制的优化。
优点
这样对网络的压力就非常小，各个节点也不必浪费 CPU 时间和内存进行大量的序列化操作。 把这种集群间数据共享的机制应用在 Session 同步上，既避免了对数据库的依赖，又能达到负 载均衡和灾难恢复的效果。
