需要粘性会话的负载平衡网络的正确设置？

Question

我找到了很多关于这个主题的问答，但我仍然没有弄清楚我们服务器的正确配置。背景是这样的：我们在负载均衡器后面有两个 Web 服务器，并且必须确保用户不会丢失他们的会话。

• Web 服务器是 IIS7/ASP.NET 4。
• 我们目前无法设置单独的会话状态服务器，因此必须在 LB 上使用粘性会话。

据我了解，必须保证以下几点：

• 在两个 Web 服务器上设置相同的机器密钥。
• 使用预编译站点，以便程序集在两台机器上获得相同的命名。
• 我们要么必须基于 ip-number 或 cookie 的粘性会话（后者是首选）

有必要有预编译的网站吗？ （我知道它更快，但我们失去了一些灵活性）

既然我们有粘性会话，那么拥有相同的机器密钥是否只会影响用户会话超时并且他/她最终在另一台服务器上的情况（这意味着包含视图状态的回发可能无效）是否正确除非他们有相同的机器密钥？）

Answer 1

您在所有方面都是正确的 - LB 上的粘性会话将确保相同的 Web 服务器将在后续请求中被命中，因此正确的进程内会话状态将可用。但是，LB 粘性必须与 ASP.NET 会话的超时值匹配（或更多）。例如，如果 LB 使用 cookie 进行粘性，那么 cookie 的过期时间应该比 ASP.NET 会话的过期时间长。

相同的机器密钥参数对于无论出于何种原因将请求回发到其他服务器的情况很有用。客户端状态（例如视图状态和事件验证，可能是身份验证票证）使用机器密钥加密，因此具有相同的密钥可确保任何服务器都可以服务回发。附带说明一下，在所有网络农场场景中，所有网络服务器上都有准确的 S/W 环境（以及可能的 H/W 环境）是 100% 有意义的，以避免任何意外。

需要预先编译网站以避免序列化冲突 - 序列化/反序列化时类型名称必须相同。因此，您不能从动态生成的程序集中获得序列化类型，并且每次编译可以避免这种情况。 IMO，这更有可能影响视图状态存储而不是会话状态（因为您的会话状态以任何方式不共享，并且在第二台服务器上不可用）。最后，如果您不使用网站而是使用 Web 应用程序项目，那么这一点或多或少变得无关紧要，因为在构建项目时无论如何都会编译代码文件。只有页面（标记）会被动态编译，并且标记中可序列化类型的机会几乎为零（无论如何听起来都是个坏主意）。