asp.net - 需要粘性 session 的负载平衡 Web 的正确设置？

Question

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

Web 服务器是 IIS7/ASP.NET 4。

我们目前无法设置单独的 session 状态服务器，因此必须在 LB 上使用粘性 session 。

据我了解，必须确保以下几点:

在两个 Web 服务器上设置相同的机器 key 。

使用预编译站点，以便程序集在两台机器上获得相同的命名。

我们要么必须基于 ip-number 或 cookie(后者是首选)建立粘性 session

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

由于我们有粘性 session ，拥有相同的机器 key 是否只影响用户 session 超时的情况，因此他/她最终在另一台服务器上(这意味着包含 View 状态的回发可能无效，除非他们有相同的机器 key ？)

Answer 1

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

对于出于任何原因将请求回发到其他服务器的情况，相同的机器 key 参数很有用。客户端状态(例如 View 状态和事件验证，可能是身份验证票证)使用机器 key 进行加密，因此具有相同的 key 可确保任何服务器都可以提供回发服务。附带说明一下，在所有 Web 场场景中，在所有 Web 服务器上拥有精确的 S/W 环境(和可能的 H/W 环境)是 100% 有意义的，以避免任何意外。

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