紧接着，客户端 1 又向服务器发送了一个请求，但是这一次请求被负载均衡给了服务器 B，而服务器 B 这时候是没有存储服务器 A 的 Session 的，这就导致 Session 的失效。
明明用户在上一个界面还是登录的，跳到下一个界面就退出登录了，这显然不合理。
当然了，对此的解决方法其实也有很多种，其实就是如何解决 Session 在多个服务器之间的共享问题：
- Sesson Replication
- Sesson Sticky
- Sesson 数据集中存储
这个是最容易想到的，既然服务器 B 没有服务器 A 存储的 Session，那各个服务器之间同步一下 Session 数据不就完了。
这种方案存在的问题也是显而易见的：
- 同步 Session 数据带来了额外的网络带宽开销。只要 Session 数据有变化，就需要将数据同步到所有其他机器上，机器越多，同步带来的网络带宽开销就越大。
- 每台Web服务器都要保存所有 Session 数据，如果整个集群的 Session 数据很多（比如很多人同时访问网站的情况），每台服务器用于保存 Session 数据的内存占用会非常严重。
从名称也能看出来，Sticky，即让负载均衡器能够根据每次的请求的会话标识来进行请求的转发，保证一个会话中的每次请求都能落到同一台服务器上面。
存在问题的：
- 如果某台服务器宕机或者重启了，那么它上面存储的 Session 数据就丢失了，用户就需要重新进行登陆。
- 负载均衡器变为一个有状态的节点，因为他需要保存 Session 到具体服务器的映射，和之前无状态的节点相比，内存消耗会更大，容灾方面会更麻烦。
将每个服务器的 Session 数据都集中存到外部介质比如 Redis 或者 MySQL 中去，然后所有的服务器都从这个外部介质中拿 Session 就行了
