Session一致性
Session复制
Tomcat1 的 Session 复制到 Tomcat2 上
缺点
- Session 复制传输需要占用内网带宽。
- 我们的例子就只有两台机器，这个复制性能还可以。但是假设我们有 N 台机器，那么每次复制都要复制给 N-1 台机器，如果机器很多，可能会形成网络风暴，复制性能也会呈指数级下降。
- Tomcat 需要保存所有的 Session 数据，这个方案的 Session 存储在内存中，容易受到机器的总内存的限制。我们没办法通过加机器的方式水平扩展，我们能做的方式就是加大机器内存。但是机器内存越大，价格很贵。
客户端存储
将Session拿出来，存到浏览器的 Cookie 中。
缺点
需要加密
Session粘滞
Nginx 会使用请求者的 IP 来做 Hash，然后分发到一台机器上，这样可以保证同一 IP 的请求都落在同一台 Tomcat 上。
也可以使用 Http 协议中的一些业务属性来做 Hash，常见的有 userId,loginId。
缺点
- 所有人的出口的 IP 都是一个，那么内部所有请求只会到一台机器上，那我们这种情况等于又变成单点了。
- 如果 Tomcat 重启，Session 由于是放置在内存内存中，这一部分的 Session 将会丢失，这就导致这部分用户将会重新登录。
后端集中存储
将 Session 单独存起来，保存到 Redis 或者 MySQL 中。
缺点
网络请求和复杂度