多服务器设置上的“进程内”会话状态模式？答案

【问题标题】：'in-proc' Session State mode on a multiple server setup?多服务器设置上的“进程内”会话状态模式？
【发布时间】：2013-08-15 15:13:09
【问题描述】：

我的团队在多服务器设置上使用“进程内”会话状态模式。这显然对我来说似乎不对，因为会话状态在每台服务器上都是唯一的，并且不会被共享。

我们已经通过在两台服务器上（在应用程序的配置文件中）提供相同的机器密钥来解决这个问题。但我觉得这实际上并没有帮助......

感谢您对此的任何说明。

谢谢！

【问题讨论】：

【解决方案1】：

当使用InProc 会话状态时，会话将本地存储在为请求提供服务的服务器上，因此在两台服务器上使用相同的机器密钥将无法达到目的。

此选项不适合在网络场环境中使用。一台农场机器存储会话状态，而另一台则不存储。来自同一用户的后续 Web 请求可能无法读取正确的会话状态。

考虑一个非常常见的场景：

假设 Web 请求被路由到农场机器 A，并且请求调用的代码依赖于会话中存储的一些参数。如果在下一个同样依赖会话状态的 Web 请求中将同一用户路由到机器 B，那么结果将是不可预测的。

有一种叫做 StickySessions 的东西可以解决上述情况。 但这真的好吗？

此功能意味着，如果客户端返回第二个请求，则负载均衡器会将流量重定向到同一 Web 服务器。它也称为客户亲和性。这对于在本地存储会话状态的 Web 服务器可能很重要，这样当同一个访问者回来时，我们不希望与该用户相关的状态不可用，因为请求被路由到了不同的 Web 服务器。

这绝对超出了网络场中负载平衡的目的。我们应该避免这种解决方案，以便负载平衡器可以根据当前负载在场中选择“正确”的机器。

【讨论】：

很好的解释，谢谢。如果它是表单身份验证或 Windows 身份验证方案，它会有所不同吗？而且，如果我们没有在会话变量中专门存储任何内容，这仍然是一个问题吗？
Windows 身份验证适用于内网场景。这不使用cookies。根据您的设置，表单身份验证可能会或可能不会使用 cookie。根据您的要求，您可能更喜欢会话变量，也可能不喜欢。
这回答了“InProc 对我有用吗？”的问题。（不）。但真正问题的答案是“我该用什么代替？”是 StateServer 或 SQLServer，请参阅msdn.microsoft.com/en-us/library/ms178586(v=vs.140).aspx

【解决方案2】：

您可以使用 AppFabric 会话状态来管理分布式会话

【讨论】：