如何跨多个 Web 服务器维护状态？答案

【问题标题】：How do I maintain state across multiple web servers?如何跨多个 Web 服务器维护状态？
【发布时间】：2010-12-06 10:26:24
【问题描述】：

我能否将多个 Web 服务器连接到一个 SQL Server 集群并仍然保持用户的会话？

我想过各种方法。 Microsoft 站点建议的方法是使用 response.redirect 到“正确”服务器。虽然我能理解其中的原因，但这似乎有点短视。

如果负载平衡器将您发送到当前压力最小的服务器，那么作为开发人员，您肯定应该尊重这一点吗？

在这种情况下是否有任何最佳做法可以遵循？如果是这样，我将不胜感激知道它们是什么以及对使用它们的利弊的任何见解。

【问题讨论】：

【解决方案1】：

一些选项：

负载平衡器可以配置为具有粘性会话。确保您的应用会话超时时间小于负载均衡器，否则您会因无法预料的结果而被弹跳。

您可以使用指定的状态服务器来处理会话。那么他们在哪里被LB反弹就无关紧要了。

您可以使用 SQL Server 来管理会话。

【讨论】：

负载均衡器？您如何摆脱这种单点故障？如果负载均衡器死了，那会怎样？是否有一种现实的方法可以避免这种情况？
至于使用SQL server来管理session，这不会带来自身的扩展性问题吗？即必须在每次页面刷新时从数据库中获取用户数据？
我实际上没有使用 SQL Server 来管理，所以我无法谈论可扩展性。我不会只有一个 LB - 我至少有 2 个，可能多达 5 个（2x 产品，2x 测试，1x 开发）
@bobthebuilder-如果您使用 SQLServer，这将是拆分到第二个数据库服务器的绝佳划分。核心数据在一个数据库服务器上，状态管理在另一个数据库服务器上。

【解决方案2】：

我从 Java 应用服务器的经验中汲取经验，其中一些具有非常复杂的平衡算法。

一个合理的一般假设是“会话关联”比平衡每个请求更可取。如果我们为每个用户分配具有某种程度的工作负载知识（甚至是随机的）的初始请求，并且人口来来去去，我们最终会得到合理的行为。请记住，目标是为每个用户提供良好的体验，而不是最终得到均匀使用的服务器！

如果服务器发生故障，我们可以看到我们的请求移动到其他地方，我们希望看到我们的会话转移。有很多方法可以实现这一点（数据库中的会话，通过高速消息传递的会话状态......）。

【讨论】：

好的，如果原始服务器发生故障或停止服务，这会导致有关传播会话状态的问题。有没有实现这一目标的最佳实践？
+1，优秀（IMO）答案，我自己也有几乎相同的内容。
@BobTheBuilder：一种选择是不要，把它放在下巴上继续前进。严重的是，如果服务器崩溃时用户不能丢失我们认为是易变的东西，那么 Session 对象不是该数据的正确位置。

【解决方案3】：

这可能不是您要寻找的答案，但您能否消除对会话状态的需求？我们已经竭尽全力在页面本身的请求之间对我们可能需要的任何内容进行编码。这样一来，我就不必担心农场的状态或不得不挂在可能永远不会回来的人拥有的东西上的可扩展性问题。

【讨论】：

我们也想过这个问题，而且可能真的会走这条路，所以我不是不想想听这个。只是我还没有准备好做出那个决定。我希望所有选项都摆在桌面上，这样我就可以做出明智的决定。我认为它对其他开发人员也很有用。

【解决方案4】：

虽然您可以在负载平衡器中使用“粘性”会话，但更理想的方法是让您的会话使用状态服务器而不是 InProc。此时，您的所有网络服务器都可以指向同一个状态服务器并共享会话。

更新：

State Server 是 Windows 服务器上的一项服务，但是它会产生单点故障。

此外，您可以指定将会话序列化到 SQL Server，如果您将其进行农场化，这将不会是单点故障。

我不确定状态服务器的工作负载有多“重”，还有其他人有任何指标吗？

【讨论】：