如何維護多個Web服務器的狀態？

Question

我可以將多個Web服務器連接到SQL Server羣集並仍然維護用戶會話嗎？

我想過各種方法。微軟網站建議使用response.redirect到「正確」的服務器。雖然我能理解這一點的推理，但它似乎有些短視。

如果負載均衡器正在將您發送到當前處於最低壓力下的服務器，那麼作爲開發人員，您應該尊重這一點嗎？

在這種情況下是否有最佳做法？如果是這樣，我將不勝感激，瞭解它們的含義以及對使用它們的利弊的任何見解。

Answer 1

某些選項：

負載均衡器可以配置爲有粘性會話。確保您的應用會話超時時間少於負載均衡器，否則您會因不可預知的結果而被反彈。

您可以使用指定的狀態服務器來處理會話。那麼它們在哪裏被LB反彈並不重要。

您可以使用SQL Server來管理會話。

在serverfault上檢查此項。 https://serverfault.com/questions/19717/load-balanced-iis-servers-with-asp-net-inproc-session

Answer 2

雖然您可以在負載均衡器中使用「粘性」會話，但更優化的途徑是讓您的會話使用狀態服務器而不是InProc。此時，您的所有Web服務器都可以指向相同的狀態服務器和共享會話。

http://msdn.microsoft.com/en-us/library/ms972429.aspx MSDN有很多關於這個問題說：d

UPDATE：

狀態服務器是在Windows服務器箱服務，但是，是它產生單一故障點。

此外，您可以指定將會話序列化到SQL Server，如果您擁有它，它不會是單點故障。

我不確定狀態服務器的負載是多麼「沉重」，其他人是否有任何指標？

Answer 3

這可能不是您正在尋找的答案，但是您能否消除會話狀態的NEED？我們已經竭盡全力在網頁本身的請求之間編碼任何我們可能需要的內容。這樣我就不用擔心農場內的狀態或者不得不掛上某個可能永遠不會回來的人擁有的東西的可擴展性問題。

Answer 4

我在這裏從我的Java應用服務器的經驗，有些非常複雜的平衡算法。

一個合理的一般假設是「會話相關性」優於平衡每個請求。如果我們爲每個用戶分配一定程度的工作量知識（或者甚至是隨機的）並且人口來來去去，那麼我們最終會得到合理的行爲。請記住，目標是給每個用戶一個不錯的體驗，不要結束使用均勻使用的服務器！

如果發生服務器故障，我們可以看到我們的請求移動eleswhere，我們希望看到我們的會話轉移。很多方法可以實現這一點（DB中的會話，通過高速消息傳播的會話狀態......）。