使用负载均衡器进行粘性会话有何不利之处？

我们有一个运行良好的IIS7计算机的Web场。在它们前面是F5 Big-IP硬件负载平衡器，也可以正常工作:)

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

目前，我们正在使用ASP.NET State Service来处理OutProc状态。当您具有Web场来维护任何类型的会话信息时，这是必需的。

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

任何人都可以阐明和/或体验吗？

有两个主要缺点：

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

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

AOL在某一时刻使用代理群集，并且确实与负载平衡器和粘性会话搞混了。现在，大多数负载平衡器将提供基于C级网络范围的粘性会话，或者对于F5，基于cookie的粘性会话将最终节点存储在Web请求cookie中。

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

综上所述，在运行带有粘性会话和过程中会话的F5的网站方面，我们取得了巨大的成功。

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

我最近在TechNet上读了一篇很棒的文章，内容是“为ASP.NET应用程序提供可伸缩性”。它涉及每种可能解决方案的利弊。阅读：

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

除了克里斯托弗（Christopher）的出色回答外，棘手的会话还意味着您已经失去了冗余服务器的许多巨大好处-能够进行一次或多次停机维护的能力以及面对系统故障时的透明性。

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