使用負載均衡器進行粘性會話的缺點是什麼？

我們有一個執行良好的 IIS7 機器網路農場。他們前面是一個F5 Big-IP硬體負載均衡器，也工作正常 :)

（來源：www.f5.com）

目前我們正在使用 anASP.NET State Service來處理我們的OutProc狀態。當您有一個網路場來維護任何類型的會話資訊時，這是必需的。

我想知道我們是否可以在 F5 Big-IP 上進行粘性會話，從而從 OutProc 更改回 InProc？如果是這樣，這樣做的缺點是什麼？我知道 InProc 與 OutProc 的缺點，所以不用擔心解釋這一點。我對沒有 F5 Big-IP 的粘性會話的利弊更感興趣。

任何人都可以提供一些啟示和/或經驗嗎？

有兩個主要缺點：

1. 您的負載分佈不均。粘性會話會堅持，因此得名。雖然初始請求將平均分配，但最終可能會有大量使用者花費比其他使用者更多的時間。如果所有這些最初都設置為單個伺服器，那麼該伺服器將有更多的負載。通常，這不會真正產生巨大影響，並且可以通過在集群中擁有更多伺服器來緩解。
2. 代理將使用者聚合成單個 IP，所有這些都將發送到單個伺服器。雖然這通常沒有害處，但除了增加單個伺服器負載之外，代理也可以在集群中執行。如果請求來自代理集群中的不同代理伺服器，則從此類系統向您的 F5 發出的請求不一定會發送回同一台伺服器。

AOL 曾一度使用代理集群，並且真的被負載平衡器和粘性會話搞砸了。大多數負載均衡器現在將提供基於 C 級網路範圍的粘性會話，或者在 F5 的情況下，基於 cookie 的粘性會話將終端節點儲存在 Web 請求 cookie 中。

雖然基於 cookie 的會話應該可以工作，但我遇到了一些問題，通常選擇基於 IP 的會話。大但是：我主要在內部應用程序上工作 - DMZ 里程可能會有所不同。

綜上所述，我們已經取得了一些巨大的成功，網站通過粘性會話和 In-Proc 會話執行 F5。

您可能還想查看記憶體分佈式記憶體系統之一，例如Memcached 或 Velocity，以替代儲存在 SQL 中的 session 或 out of proc 記憶體服務。您可以在多個伺服器上執行它，從而接近程序內記憶體的速度。

引用自：https://serverfault.com/questions/46307