分布式一致性 Session

    单机部署的时候，登录之后将会把用户登录信息放在 Session 中，
	用户每次操作首先先校验 Session 是否存在用户信息，如果不存在
	将会强制让用户先去登录。
    
    所有操作都在一台 Tomcat 上，这当然没有什么问题。
    
    集群部署之后，由于 Nginx 使用默认负载均衡策略（轮询），请求将
    会按照时间顺序逐一分发到后端应用上。也就是说刚开始我们在 
    Tomcat1 登录之后，用户信息放在 Tomcat1的 Session里。过了一
    会，请求被 Nginx 分发到了 Tomcat2 上，这时 Tomcat2上 
    Session里还没有用户信息，于是又要登录。

分布式一致性 Session 解决办法

Session 复制

如果此时 Tomcat1 Session 存在用户信息，而 Tomcat2 上没有存在。

这时如果我们将 Tomcat1 的 Session 复制到 Tomcat2 上，后面 Nginx 将请求转发到 Tomcat2 上，由于 Tomcat2 存在 Session ，这时就不需要再重新登录了。

缺点：

• Session 复制传输需要占用内网带宽。
• 我们的例子就只有两台机器，这个复制性能还可以。但是假设我们有 N 台机器，那么每次复制都要复制给 N-1
  台机器，如果机器很多，可能会形成网络风暴，复制性能也会呈指数级下降。
• Tomcat 需要保存所有的 Session 数据，这个方案的 Session
  存储在内存中，容易受到机器的总内存的限制。我们没办法通过加机器的方式水平扩展，我们能做的方式就是加大机器内存。但是机器内存越大，价格真的很贵！！！

Session 前端存储

将用户信息存储在cookie，返回给前端，存到浏览器的 Cookie 中。
每个用户浏览器存储自己的 Cookie 信息，服务端就不需要存储，这就解决了 Session 复制方案的缺陷了。
接下来用户每次请求都把这个 Cookie 给我发过来，我判断 Cookie 里面用户信息不就好了。

缺点：

• 用户信息可是我们的敏感数据，不能让别人轻易的窃取或者篡改数据了。
• 这个方案每次请求都要携带 Cookie 传输，这会占用外网的带宽，如果 Cookie 过大，会增大网络的开销。
• 我们存储的数据大小，容易受到 Cookie 限制。

Session 粘滞（Sticky Sessions）

修改 Nginx 默认的负载均衡策略，使用 IP Hash 的方式。
Nginx 会使用请求者的 IP 来做 Hash，然后分发到一台机器上，这样可以保证同一 IP 的请求都落在同一台 Tomcat 上。

缺点：

• Tomcat 重启，Session 由于是放置在内存内存中， Session 将会丢失，这就导致这部分用户将会重新登录
• 临时再加机器，修改完 Nginx 配置，重新启动之后，Nginx 将会重新计算 Hash 分发请求

后端集中存储

Session 存储在应用内存上，应用机器只要重启，Session 就会丢失。
为了这个解决这个问题，我们将 Session 单独存起来，保存到 Redis 或者 MySQL 中。不过由于 Session 需要过期失效的特性，不需要持久化保存，建议使用 Redis 来保存。