使用主动/主动粘滞会话的SignalR和负载平衡

我们有一个使用SignalR更新客户端UI的应用程序，目前该应用程序托管在我们维护的IIS上，我们的客户直接与我们保持联系。使用主动/主动粘滞会话的SignalR和负载平衡

然而，我们正在将其整合到整个企业范围内的框架中，我们的应用程序将保留在自身内部，但是我们将继续托管应用程序，但是登陆我们网页的任何人都会通过我们所知道的是“每个区域设置为2个网关服务器的负载平衡策略为主动/主动与粘滞会话”

我的问题是，当SignalR决定选择长轮询作为传输协议并以某种方式连接时，我们会遇到任何问题被丢弃？

对不起，但我真的没有任何关于负载平衡的知识。

任何帮助都非常赞赏。

2012-08-10 MaYaN

好吧，假设你真的使用“粘性”会话，那么连接丢失应该无关紧要，因为下一个请求应该返回到同一个底层服务器，因为粘滞性。毕竟，粘性会话都是关于如何在一些请求过程中保持HTTP的标准请求/响应模型回到同一台服务器。所以，由于长时间轮询只不过是一个长时间/流式响应的标准请求，它应该很好地与标准的粘性会话实现集成在一起。

您需要考虑的是：如果由于失败或维护而导致服务器A丢失，会发生什么情况？如果您没有使用扩展的消息总线解决方案（Redis，Azure SB），则可能会在从服务器A转换到服务器B时丢失/丢失消息。

来源

2012-08-10 17:13:15

感谢您的解释，关于您的问题，如果我要求SignalR重新连接“断开”，仍然会出现问题？当然，重新衔接的时间应该已经完成。 – MaYaN 2012-08-10 18:12:50

如果负载均衡器正在做它的工作，你应该重新连接到服务器B.我只是说，你可能会失去一个重要的信息，应该从服务器A发送，但不是因为它死亡/被采取它可以发送前离线。如果它只是某种聊天应用程序，那不是什么大问题。 – 2012-08-10 18:41:10

嘿！是的，这实际上是值得与有关部门调查的好点，因为我们承受不起任何信息。谢谢你的帮助：-） – MaYaN 2012-08-10 22:24:57

使用主动/主动粘滞会话的SignalR和负载平衡

回答

相关问题