SignalR和负载平衡与主动/主动粘滞会话
我们有一个使用SignalR更新客户端UI的应用程序，目前该应用程序托管在我们维护的IIS上，我们的客户直接与我们保持联系。
然而，我们正在将其整合到整个企业范围内的框架中，我们的应用将保留在自身内部，但是我们将继续主持该应用，但是登陆我们网页的任何人都将经历我们所知道的负载平衡战略。 “每个区域的2个网关服务器设置为活动/活动并使用粘性会话”
我的问题是，在SignalR决定选择长轮询作为传输协议并且连接断开的情况下，我们是否会遇到任何问题？
对不起，但我真的没有任何关于负载平衡的知识。
任何帮助都非常赞赏。
那么，假设你真的使用“粘性”会话，则连接丢失应该无关紧要，因为下一个请求应该返回到同一个基础服务器，因为粘滞性。 毕竟，粘性会话都是关于如何在一些请求过程中保持HTTP的标准请求/响应模型回到同一台服务器。 所以，由于长时间轮询只不过是一个长时间/流式响应的标准请求，它应该很好地与标准的粘性会话实现集成在一起。
您需要考虑的是：如果由于失败或维护而导致服务器A丢失，会发生什么情况？ 如果您没有使用扩展的消息总线解决方案（Redis，Azure SB），则可能会在从服务器A转换到服务器B时丢失/丢失消息。
链接地址: http://www.djcxy.com/p/62223.html上一篇: SignalR and Load Balancing With Active/Active Sticky Sessions