适合需要粘性会话的负载平衡Web的正确设置？

Question

我发现很多q & a在这个问题上，但我仍然没有想出我们的服务器的正确配置。背景是：我们在负载均衡器后面有两个Web服务器，并且必须确保用户的会话不会松动。

• Web服务器IIS7是/ ASP.NET 4
• 我们目前无法建立一个单独的会话状态服务器，并为此必须在LB的使用粘性会话

据我了解，下面用得放心：

• 设置相同的machineKey两个Web服务器上。
• 使用预编译的网站，以便组件在两台机器上获得相同的命名。
• 我们要么必须基于IP的数字或饼干（后者是首选）

是否有必要粘性会话有预编译的网站？ （我知道速度更快，但是我们失去了一些灵活性）

由于我们有粘性会话，具有相同机器键的情况是否正确只会影响用户会话超时和因此他/她因此而结束的情况服务器（这意味着包含视图状态的回贴可能无效，除非它们具有相同的机器密钥？）

Answer 1

你在所有观点上都是正确的 - LB上的粘性会话将确保相同的Web服务器将在后续请求中被命中因此正确的进程内会话状态将可用。但是，它的迫切性LB粘性应该与ASP.NET会话的超时值相匹配（或者应该更多）。例如，如果LB使用cookie来实现粘性，那么cookie的过期时间应该多于ASP.NET会话的过期时间。

相同的机器键参数对于任何原因发送请求发回其他服务器的情况很有用。客户端状态（如视图状态和事件验证，可能是身份验证票证）使用机器密钥进行加密，因此具有相同的密钥可确保任何服务器都可以为后端服务。请注意，在所有Web场景中，为了避免任何意外，在所有Web服务器上都具有精确的S/W环境（以及可能的H/W环境）是100％的意义。

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