SignalR 和负载平衡与主动/主动粘性会话

Question

我们有一个使用 SignalR 更新客户端 UI 的应用程序，目前该应用程序托管在我们维护的 IIS 上，我们的客户直接与我们连接。

但是，我们正在将其集成到一个企业范围的框架中，该框架将容纳我们的应用程序，我们将继续托管该应用程序，但是任何登陆我们页面的人都会经历我们被告知的负载“每个区域的 2 个网关服务器设置为活动/活动和粘性会话”的平衡策略

我的问题是，当 SignalR 决定选择长轮询作为传输协议并且以某种方式断开连接时，我们会有什么问题吗？

抱歉，我对负载平衡这一主题一无所知。

非常感谢任何帮助。

Answer 1

好吧，假设您真的在使用“粘性”会话，那么断开连接应该无关紧要，因为由于粘性，下一个请求应该返回到同一个底层服务器。毕竟，粘性会话都是为了在多个请求的过程中保持标准的 HTTP 请求/响应模型返回到同一台服务器。因此，由于长轮询只不过是具有延长/流式响应的标准请求，因此它应该与标准粘性会话实现很好地集成。

您需要考虑的是：如果您因为故障或维护而失去服务器 A，会发生什么？如果您没有使用横向扩展的消息总线解决方案（Redis、Azure SB），您可能会在从服务器 A 转换到服务器 B 时丢失/错过消息。