做web开发的学生应该很熟悉session，这是服务器分配给客户端的会话id，浏览器在每个请求中都有这个id告诉服务器我是谁，服务器通过将这些不同的会话信息存储在内存中在独立部署的环境中，web服务和session位于同一台计算机上，因此可以找到相应的会话数据。 但是，在两台web服务器( A和B )提供服务的情况下，如果最初的请求落在A上而创建了session，海瑶网站建设公司如何才能使下一个落在B上的请求读取session数据呢？

解决方案

有以下4种一般解决方案。

1、会话堆叠

这是最简单粗暴的方法。 核心思想是让同一会话的所有请求落地到同一台服务器上。 这样的话，就可以像独立的一样处理。 在负载均衡的基础上建立一些身份，通过控制传输，可以达到这个目的。 这样做的好处是可以像独立一样简化会话处理，也可以轻松进行本地缓存，但缺点也很明显。

如果此服务关闭或重新启动，会话数据将会丢失，分布式群集的高可用性功能将会丢失。

负载平衡器的负担增加，有状态，资源消耗增加，容易成为性能瓶颈。

2、会话复制

顾名思义，这是一种会话复制方案，其核心思想是通过在服务器之间添加会话同步机制来确保数据的一致性。

虽然看起来比第一个简单得多，也没有第一个带来的缺陷，但是在一些APP场景中存在严重的问题：

服务器之间的数据同步会带来额外的网络消耗，随着机器数量和数据量的上升，网络带宽承受着巨大的压力，延迟问题也必然会出现。

每个服务都存储所有会话数据。 如果会话数量很大，服务器的大部分内存空间将被占用。

当群集规模和数据量相对较小时，这是一个很好的解决方案，因为当前许多APP应用程序容器都支持这种同步方法。

3、会话集中存储

这种做法的理念是将所有会话数据整合起来存储和管理。 所有APP应用程序服务都必须通过session服务进行操作，才能对session进行读写。

这种方案的好处是，session的管理、责任的单一化、session服务以什么方式存储(内存、数据库、文档、NoSql等)、以什么方式对外提供服务都是透明的它看起来很完美，但也有一些小缺点，因为它不会给APP应用系统和负载平衡带来额外的开销，而且可以在不同步数据的情况下确保一致性。

对session的读写需要网络操作，与session直接存储在web服务器上相比，增加了延迟和不稳定性。 幸运的是，session和web服务器通常部署在局域网中，因此可以最大限度地减少这一问题。

如果session服务器出现问题，则会影响所有web服务，多台机器的部署也会带来数据完整性问题。

每种方案都有其独特的优势，同时也带来相应的新问题。 没有完美，就意味着只有符合才是最好的。 一般来说，当APP应用程序服务器和会话数据量较大时，此方案非常有利。

4、Cookie Base

该方案是基于cookie的传输实现的。 核心思想简单，处理完完整的会话数据后写入客户端cookie，以后每次客户端请求时都带上这个cookie，服务端通过分析cookie数据获取会话信息。 下图：

这个方案很简单，也没有前面几个方案带来的问题，但劣势也非常明显：

首先使用cookie传递重要数据，即使采用特殊的加密手段也一定不安全。

如果客户端禁用cookie，则服务将无法直接使用。

cookie的数据有大小限制，如果传输的数据超过限制大小，数据就会异常。

在http请求中携带和传输大量数据会增加网络负担。 同样，服务器端响应大量数据会导致请求变慢，如果并发量大，这将非常可怕。

总结

以上四种方案都是可行的方案，但如前所述，各方案各有优劣，并非十全十美，实用上要根据需求进行权衡和取舍。 虽然这些是比较常见的方案，但我相信在真正的实践和落地过程中会出现其他问题。 有经验的人可能有另辟蹊径的“路”。 欢迎讨论交流。

详情请访问云服务器、域名注册、虚拟主机的问题，请访问西部数码代理商官方网站： zhuji.chenqinet.cn