我们有一个由 IIS7 机器组成的网络农场，它们运行良好。它们前面是F5 大 IP硬件负载平衡器，也运行良好:)
（来源：www.f5.com）
目前我们正在使用ASP.NET State Service来处理我们的输出处理状态。当您拥有一个 Web 场来维护任何类型的会话信息时，这是必需的。
我想知道我们是否可以粘性会话在 F5 Big-IP 上，因此从 OutProc 改回 InProc？如果是这样，这样做的缺点是什么？我知道 InProc 与 OutProc 的缺点，所以不必费心解释。我更感兴趣的是不使用 F5 Big-IP 的粘性会话的优点/缺点。
有人可以提供一些启示和/或经验吗？
答案1
主要有两个缺点：
您的负载分布不均匀。粘性会话会粘住，因此得名。虽然初始请求会均匀分布，但最终可能会有相当多的用户比其他用户花费更多的时间。如果所有这些最初都设置为单个服务器，则该服务器的负载会大得多。通常，这不会产生很大的影响，可以通过在集群中增加更多服务器来缓解。
代理将用户集中到单个 IP，所有 IP 都会发送到单个服务器。虽然这通常不会造成任何损害，但除了增加单个服务器负载外，代理还可以在集群中运行。如果请求来自代理集群中的不同代理服务器，则从此类系统发送到 F5 的请求不一定会发送回同一台服务器。
AOL 曾一度使用代理集群，并真正搞砸了负载平衡器和粘性会话。大多数负载平衡器现在将提供基于 C 级网络范围的粘性会话，或者像 F5 那样，提供基于 cookie 的粘性会话，将终端节点存储在 Web 请求 cookie 中。
虽然基于 cookie 的会话应该可以工作，但我遇到了一些问题，通常选择基于 IP 的会话。然而，我主要在内部应用程序上工作 - DMZ 里程可能会有所不同。
综上所述，我们在使用粘性会话和进程内会话运行 F5 后的网站方面取得了巨大的成功。
你可能还想看看内存分布式缓存系统，例如Memcached 或 Velocity这是一种替代将会话存储在 SQL 中或进程外内存服务的替代方案。您可以接近进程内内存的速度，并能够在多个服务器上运行它。
答案2
除了克里斯托弗的出色回答之外，粘性会话意味着您失去了冗余服务器的一些巨大好处——能够关闭一台或多台服务器进行维护，以及在系统故障时的透明度。
我认为粘性会话是应用程序架构不佳和/或编程不佳的强烈指标。“不惜一切代价避免”是我的座右铭。
答案3
我最近在 TechNet 上读到一篇关于“为 ASP.NET 应用程序提供可扩展性”的很棒的文章。它深入探讨了每种可能的解决方案的优缺点。请阅读：