网络负载平衡场景中的会话状态答案

【问题标题】：Session state on a network load balance scenario网络负载平衡场景中的会话状态
【发布时间】：2010-07-20 20:41:56
【问题描述】：

我们目前已经为一个站点设置了当前服务器：

服务器 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 上设置一个虚拟目录，这将指向一个网络共享映射到管理站点上的上传目录，有什么理由不赞成这样做吗？

为我的无知道歉，这对我来说是未知的领域！

谢谢，肖恩

【问题讨论】：

【解决方案1】：

取决于你想要什么状态服务。

通常在负载平衡的情况下，您会选择 SQL Server Session 或 ASP.NET State 服务。

各有优缺点（SQL Server Session 需要序列化/反序列化，但在服务器故障时保持状态，ASP.NET State 在服务器故障时不保持状态，但由于没有序列化/反序列化，速度要快得多)。

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

关于这两个方面的讨论需要您进一步研究——因为您主要关心的是可用性还是速度。

请记住，如果您想在 web 服务器（即 webfarm）之间共享会话，您需要更新每台服务器的 machineKey 设置以使其相同。

Here's 一篇关于 ASP.NET 会话状态（以及我提到的 machineKey 问题）的好文章。

【讨论】：

谢谢。该应用程序非常依赖会话，所以我认为我们现在将使用 StateServer，因为它似乎是更快的方法。它将指向一个单独的服务器，因此资源现在不是真正的问题。我在回复之前大约 10 分钟找到了您引用的文章，很高兴看到它具有一定的可信度！谢谢。

【解决方案2】：

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

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

【讨论】：

我们在实现负载平衡之前最初使用的是 SQL Server，后来因为我们发现它更快，所以改为使用 StateServer。如果它更快，将其保留为 StateServer 是否有意义？鉴于我们要在这里获得最佳性能，我更倾向于将其保留为 StateServer。
您可以使用状态服务器，但我知道没有技术可以处理状态服务器故障/故障转移。使用 SQL Server 很容易做到这一点。如果您不愿意设置 SQL 集群/故障转移，那么状态服务器就可以了。

【解决方案3】：

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

您可以在此处配置负载平衡器以始终将给定的“会话”定向到同一个框。大多数（如果不是全部）商业负载均衡器都支持这一点。基本上，他们插入自己的会话 cookie 或 http 标头，用于识别给定的用户会话。然后，此会话将始终路由到同一个框（除非它关闭）。

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

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

【讨论】：

我可以从这个解决方案中看到的唯一问题是我们将让服务器离线以部署升级。使用这种方法需要我们等到相关服务器上没有用户，并且考虑到应用程序的性质，这可能需要相当长的时间。不过还是谢谢你的回复！听到我没有考虑过的其他替代方案总是有用的。
@seanxe。绝对是的 - 这是这种方法的明显弱点。我本人并不是粘性会话的忠实拥护者（因此我明确指出了缺点），但认为将其混入其中会很有用！

【解决方案4】：

如果您想要可用性（即会话在任何服务器上都可用，而不管服务器故障），那么 SQL 路由是可行的方法，但您也可以查看 ScaleOut SessionServer (http://www.scaleoutsoftware.com/pages/products/scaleout-sessionserver.php)

干杯

猫

【讨论】：

我们追求的不是更高的可用性，而是更高的速度和性能。我们有一个非常强大的系统设置来处理停机时间（诚然不是完美的，没有什么是），所以目前我想增加网站的加载时间/性能，然后我们可以开始考虑 100% 的正常运行时间。感谢您的链接，但会调查它。