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

主要有两个缺点：

1. 你的负载不均匀分布。 粘滞的会议将坚持，因此名称。 虽然最初的请求将平均分配，但最终可能会有相当数量的用户花费更多的时间。 如果所有这些都初始设置为单个服务器，该服务器将负载更多。 通常情况下，这不会有太大的影响，并且可以通过在群集中安装更多的服务器来缓解。

2. 代理将用户组合成单个IP，所有这些都将被发送到单个服务器。 虽然这通常不会造成任何伤害，但是除了增加单独的服务器负载之外，代理也可以在集群中运行。 如果请求从其代理服务器集群中的不同代理服务器传出，则从此系统向F5发出的请求不一定会被发回到同一台服务器。

美国在线有一次使用代理集群，并真正与负载平衡器和粘性会话搞砸。 大多数负载平衡器现在将提供基于C-Classnetworking范围的粘性会话，或者基于Cookie的粘性会话F5的情况，该会话将terminal节点存储在Web请求Cookie中。

虽然基于cookie的会话应该可以工作，但我遇到了一些问题，通常select基于IP的会话。 但是，大多数情况下，我主要在内部应用程序上工作 – DMZ的微软可能会有所不同。

所有这一切都表明，我们已经取得了一些非常成功的网站运行粘着会议和进程会议。

你也可能想看看内存分布式caching系统，如Memcached或Velocity ，以替代存储在SQL中的会话或超出proc内存服务。 您可以近距离处理内存的速度，并可以在多台服务器上运行。

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

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

除了克里斯托弗的出色答案外，粘性会话意味着您已经失去了冗余服务器的巨大优势 – 维护一个或多个服务器的能力，以及面对系统故障时的透明度。

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