网络负载均衡场景下的会话状态

Question

3

我们目前为一个网站设置了以下服务器：

服务器2和3使用Windows网络负载平衡系统进行管理。它们都运行着公共站点代码的副本。

这些站点严重依赖于会话，因为它们需要处理用户登录。我的问题是：

如何在服务器之间保留状态？

公共站点的web.config目前如下：

<sessionState mode="StateServer" cookieless="false" timeout="40" stateConnectionString="tcpip=localhost:42424"/>

我想只需要将“localhost”更改为我想要存储会话的IP地址即可。我考虑使用数据库服务器来存储会话，因此它应该是这样的：

<sessionState mode="StateServer" cookieless="false" timeout="40" stateConnectionString="tcpip=databaseserverIP:42424"/>

这样做明智吗？

我发现关于这个问题有很多相互矛盾的文档，如果有人能提供他们以前/现在如何处理的见解，那会很感激。

另外（顺便提一下！），管理员系统允许您上传文章图片。我正在考虑在服务器2和3上设置虚拟目录，该目录将指向网络共享，映射到管理站点上的上传目录，是否有任何理由反对这样做？

对不起，我的无知，这对我来说是未知领域！

谢谢，Sean

- royse41

4个回答

2

您应该使用 SQL 数据库来存储会话。将 mode="SqlServer" 设置，并运行 aspnet_regsql 来将会话表添加到您的数据库中。

此外，您需要确保存储在会话中的任何对象都标记为 [Serializable]。

- matt-dot-net

我们在实施负载均衡之前最初使用了SQL Server，然后改用StateServer，因为我们发现它更快。如果StateServer更快，保持不变是有意义的吗？既然我们追求最佳性能，我更倾向于将其保持为StateServer。 - royse41

1

你可以使用状态服务器，但是我不知道有什么技术可以处理状态服务器的故障/故障转移。这在 SQL Server 中很容易实现。如果您不想设置 SQL 集群/故障转移，则状态服务器也可以。 - matt-dot-net

1

另一种考虑的方法是“粘性”会话。

这是您配置负载均衡器始终将给定的“会话”定向到同一台服务器的方法。大多数商业负载均衡器都支持此功能。基本上，它们会插入自己的会话 cookie 或 http 标头，用于标识给定的用户会话。然后，该会话将始终路由到同一台服务器（除非它停机）。

这种方法的优点是您可以继续使用普通会话状态，因此简化了服务器配置和设置。

缺点是您没有故障转移冗余，因为单个服务器的损失仍将导致其上的所有会话丢失，并且它会影响整体负载平衡性能，因为它无法像在一个服务器开始过载时那样动态调整（它可以将新会话路由到另一个服务器，但必须继续将现有会话发送到同一台服务器。）

- Rob Levine

我能看到这个解决方案唯一的问题就是我们需要下线服务器来部署升级。使用这种方法需要等待相关服务器没有用户访问，而考虑到应用程序的性质，这可能需要相当长的时间。但还是谢谢您的回复！总是很有用听到其他我没有考虑过的解决方案。 - royse41

@seanxe。绝对是的-这种方法确实存在明显的弱点。我本人其实并不是黏性会话的忠实拥趸，（因此我才明确列出了缺点），但我认为把它加入到讨论中可能会有用！ - Rob Levine

0

如果你想要高可用性（即会话在任何服务器上都可以使用，而不受服务器故障的影响），那么 SQL 是一种选择，但你也可以查看 ScaleOut SessionServer (http://www.scaleoutsoftware.com/pages/products/scaleout-sessionserver.php)。

干杯！

猫

- Cheshire Cat

我们所追求的不仅仅是可用性，更多的是速度和性能。我们已经建立了一个相当强大的系统来处理停机时间（诚然并不完美，没有什么东西是完美的），所以目前我想提高网站的加载时间/性能，然后我们就可以开始考虑100％的正常运行时间。不过感谢提供链接，会进一步了解的。 - royse41

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- RPM1984 · Accepted Answer

取决于您需要的状态服务。

通常在负载均衡的场景中，您可以选择SQL Server Session或ASP.NET状态服务。

每种方式都有其优缺点（SQL Server Session需要序列化/反序列化，但如果服务器出现故障，则可以保持状态；ASP.NET State如果服务器故障则无法保持状态，但由于没有序列化/反序列化操作，速度更快）。

无论如何，考虑将服务托管在单独的独立机器上，这样它就不会与其他进程争夺资源。

关于这两种方法的讨论需要您进一步研究，以确定可用性或速度是您的首要关注点。

请记住，如果您想在Web服务器之间共享会话（例如Webfarm），则需要将machineKey设置更新为每个服务器相同。

这里有一篇关于ASP.NET Session State的好文章（我提到的machineKey问题也在其中）。