对于聊天应用程序，我使用Azure架构和SignalR，web角色充当SignalR服务器（消息不是广播类型，但是针对特定用户/客户端）。
我想扩展SignalR服务器以及web角色，以处理繁重的用户负载。虽然SignalR文档不建议使用背板（Redis，服务总线）的预烘焙SignalR扩展方法，因为当更多用户连接（或在用户事件驱动的场景中）消息数量增加时。它明确指出：“客户端到客户端（例如，聊天）：在这种情况下，如果消息数量与客户端数量成比例，则背板可能是瓶颈;也就是说，如果消息速率增长按比例增加客户加入。“
问题： 有没有人知道任何针对这种高频情况的自定义横向扩展解决方案，它不会将消息推送到每个服务器实例或其他一些横向扩展解决方案？
已经在SignalR文档和相关视频中随处可见，但找不到任何内容，除了“过滤总线”这个词，没有解释它是什么以及应该如何使用它。
答案 0 :(得分：2)
我自己想出来了：基本的想法是服务器亲和力/粘性会话。
每个web-role实例都充当独立的SignalR服务器。在第一次连接时，我让Azure负载均衡器选择任何web-role实例，并在地图中使用客户端标识符保存该Web角色实例的IP地址。如果有来自同一客户端的另一个连接请求（例如，在页面刷新之后），那么我检查当前角色实例的IP地址，如果它与map中的条目匹配，那么我让它继续，否则我断开客户端并将其连接到正确的web-role实例。
每个worker-role实例也充当SignalR .net客户端，并连接到所有可用的SignalR服务器（web-role的所有实例）。在向SignalR服务器（web-role）发送消息之前，我在地图中查找以确定正确的SignalR服务器实例（取决于预期的JS接收者）。
<强>优势：
不需要背板技术（因此在消息传递方面没有延迟）。
每个Web角色实例都关心与其连接的客户端，并且每条SignalR服务器上都不必复制每条消息。因此它可以很好地扩展。
易于实施。