组长，赏识看了一下我：

对，你这个计划的确可行。

不过么，假如用这种计划，首要你要想好加密计划。

用户信息可是咱们的敏感数据，不能让他人轻易的盗取或许篡改数据了。

除了这个，这个计划每次恳求都要带着 Cookie 传输，这会占用外网的带宽，假如 Cookie 过大，会增大网络的开支。

别的，咱们存储的数据大小，简单受到 Cookie 约束。

所以这种仍是不怎么常用，不过也是一种思路。

我比较引荐下面两种计划。

Session  粘滞（Sticky Sessions）

组长：

刚才应该看到了，我只是对 Nginx 的装备做了一些修正，然后这个问题就处理了吧。

其实这是因为我修正 Nginx 默认的负载均衡战略，运用 IP Hash 的方法。

Nginx 会运用恳求者的 IP 来做 Hash，然后分发到一台机器上，这样能够确保同一 IP 的恳求都落在同一台 Tomcat 上。

架构图如下：

Session 粘滞-IP Hash

上面这种方法咱们运用 Nginx 四层负载均衡方法，其实 Nginx 还能够做到七层负载均衡方法，也便是运用 Http 协议中的一些事务属性来做 Hash，常见的有 userId,loginId等等。

架构图如下：

一致性 Session-Session 粘滞-七层

阿粉：

这种计划看起来挺简单的，咱们只需求修正 Nginx 装备就好了，运用端装备无需改动。

只需恳求来历 IP 满足的随机，那么 IP HASH 之后两台运用上的流量将会满足随机。

别的后边假如两台机器扛不住，咱们还能够水平扩展，再加机器，只需修正 Nginx 装备即可。

组长：

你说的这几点都很正确！

不过你有没有想过，像咱们公司这种状况，一切人的出口的 IP 都是一个。那么咱们公司的一切恳求只会到一台机器上，那咱们这种状况等于又变成单点了。

别的假如 Tomcat 重启，Session 由所以放置在内存内存中，这一部分的 Session 将会丢掉，这就导致这部分用户将会从头登录。

最后，假如咱们临时再加机器，修正完 Nginx 装备，从头启动之后，Nginx 将会从头核算 Hash 分发恳求。

这种状况就会导致有一部分用户从头路由到一台新机器上，因为没有 Session，又需求从头登录了。

不过么，Tomcat 重启或许新加机器次数不会许多，所以这个问题也不大，用户体验稍差点。

今天的咱们这个问题处理计划就先运用这个。

不过后边咱们仍是改成下面这种方法。

后端会集存储

组长：

上面几种的方法咱们都是把 Session 存储在运用内存上，运用机器只需重启，Session 就会丢掉。

为了这个处理这个问题，咱们将 Session 独自存起来，保存到 Redis 或许 MySQL 中。

不过因为 Session 需求过期失效的特性，不需求持久化保存，所以这儿我建议运用 Redis 来保存。

这样架构就变成下方这样的：

一致性 Session-Session 后端存储

咱们运用这种计划，上没有 Session 丢掉的危险，当然前提是 Redis 不能宕机。

别的后期假如运用能够直接水平扩展。

假如后边运用的恳求量很大，一台 Redis 扛不住了，那咱们能够其实能够做集群扩展，根据缓存 Key 做路由。

阿粉：

对对，这种方法好~

组长：

你不要高兴的太早，咱们运用这个计划需求付出必定的代价的。

首要咱们每次恳求都需求调用一次 Redis ，这就添加一次网络的开支。

别的，引入 Redis，咱们需求对相应的代码做出修正，这样复杂度就变高。

所以说，这个计划有利也有弊，当然对于咱们的场景来说，利大于弊。

阿粉：

恩，好像是这样的。

组长:

好了，这么晚了，问题处理了，咱们去撸个串，我请客！

阿粉：

老迈，