负载均衡器的粘性会话有什么缺点？

Question

我们有一个运行良好的 IIS7 机器的网络农场。在他们面前的是一个F5 Big-IP硬件负载均衡器，也工作正常:)

_{（来源：www.f5.com）}

目前我们使用 anASP.NET State Service来处理我们的OutProc状态。当您有一个网络场来维护任何类型的会话信息时，这是必需的。

我想知道我们是否可以在 F5 Big-IP 上进行粘性会话，从而从 OutProc 改回 InProc？如果是这样，这样做的缺点是什么？我知道 InProc 与 OutProc 的缺点，所以不用担心解释。我对没有 F5 Big-IP 的粘性会话的利弊更感兴趣。

任何人都可以阐明一些观点和/或经验吗？

Answer 1

有两个主要缺点：

1. 您的负载分布不均。粘性会话会坚持下去，因此得名。虽然初始请求将平均分配，但最终可能会有大量用户花费比其他人更多的时间。如果所有这些最初都设置为单个服务器，则该服务器将具有更多负载。通常，这不会真正产生巨大影响，并且可以通过在集群中拥有更多服务器来减轻影响。

2. 代理将用户聚合为单个 IP，所有这些 IP 都将发送到单个服务器。虽然这通常没有坏处，但除了增加单个服务器负载之外，代理也可以在集群中运行。如果请求来自代理集群中的不同代理服务器，则从此类系统到 F5 的请求不一定会发送回同一服务器。

AOL 曾一度使用代理集群，并且真的被负载平衡器和粘性会话搞砸了。大多数负载均衡器现在将提供基于 C-Class 网络范围的粘性会话，或者在 F5 的情况下，基于 cookie 的粘性会话将端节点存储在 Web 请求 cookie 中。

虽然基于 cookie 的会话应该可以工作，但我遇到了一些问题，通常选择基于 IP 的会话。然而，大：我主要在内部应用程序上工作 - DMZ milage 可能会有所不同。

综上所述，我们在运行具有粘性会话和进程内会话的 Beh F5 的站点方面取得了一些巨大的成功。

您可能还想查看内存分布式缓存系统之一，如Memcached 或 Velocity，以替代存储在 SQL 中的会话或进程外内存服务。您可以在多个服务器上运行它，从而接近进程内内存的速度。

Answer 2

除了克里斯托弗的出色回答之外，粘性会话还意味着您失去了冗余服务器的一些巨大好处——能够关闭一台或多台服务器进行维护，以及在面对系统故障时的透明度。

我认为粘性会话是不良应用程序架构和/或不良编程的有力指标。“不惜一切代价避免”是我的座右铭。

Answer 3

我最近在 TechNet 上阅读了一篇关于“为 ASP.NET 应用程序提供可扩展性”的精彩文章。它讨论了每种可能解决方案的优缺点。读一读：

TechNet 2009 年 6 月 - 为 ASP.NET 应用程序提供可扩展性