1
我們在大型Web應用程序中使用SignalR。我們部署了多個處理signalR連接的Web服務器。我們有我們自己的Redis背板，我有以下問題： SignalR對服務器進行三次調用：1）協商，2）連接和3）啓動。如果我們在Load Balancer後面有一個Web場，並且這三個調用最終會連接到三臺不同的服務器，那麼連接狀態是否會在所有三臺服務器上損壞？在這種情況下會發生什麼？我不是在談論消息傳遞。Web農場中的SignalR連接管理
更具體地說：
會第二web服務器能夠理解通過談判調用生成的的ConnectionId ？
在物理連接（的WebSockets）是在不同的服務器上建立 ，然後開始通話轉到另一個 服務器會發生什麼？
我知道SignalR沒有傳達服務器之間的連接信息。我想知道這三臺服務器的內存連接狀態。 我讀了與此相關的另一個問題，但它只談論消息傳遞。對我們來說，信息傳遞不是問題。如果這三個調用最終轉到不同的服務器，我想了解連接的最終狀態。
，我已經經歷得到答案的問題： SignalR connection affinity in web-farm scenario
由於我們的負載均衡器保持粘性，我無法確認什麼時候會發生粘性消失。我想爲這種可能性做好準備。
嘿guruprasath，只是想知道如果你得到的回答這個問題？目前，我們有一個服務於該應用程序的服務器場，我們使用的是Azure中託管的Redis背板。在我的情況下，負載平衡器沒有粘性會話，我看到超時並斷開與websocket，我相信這是你所擔心的。我感到困惑的部分是基於我在文檔中讀到的內容，傳輸連接直接與背板連接，這意味着負載均衡器沒有什麼區別......但我們沒有看到單個節點環境的問題。 – ammills01
@ ammills01，我沒有得到答案。我嘗試在另一個jabber頻道發帖，但沒有運氣。根據你所描述的，我猜你的問題與粘性無關。我們使用我們自己的Redis集羣來定製背板。所以，我無法談論他們提供的Redis背板的穩定性。我的理解是，傳輸連接不是背板（這將是一個安全問題）。傳輸連接與前端Web服務器支持websockets。所以，負載平衡器的粘性可能很重要。 – guruprasath
感謝您的回覆。在進一步挖掘之後，我得出了與此處提到的相同的結論，傳輸是在SignalR服務器上進行的，因此請求中沒有粘滯的會話就會反彈並失敗。當發生這種情況時，你會得到超時，如果你配置了longPolling或其他傳輸技術，當你建立你的SignalR連接時，它將會故障轉移到其中一個。對我們來說，它擊中longPolling並且應用程序似乎可以正常工作，只需要更多的服務器資源。 – ammills01