我很难确定在我的场景中是否需要使用Signalr背板。不幸的是，我无法获得我自己测试所需的测试环境，所以我来到这里；）
在我的场景中，我们使用signaler与来自服务器应用程序的特定客户端通信（使用连接id），该应用程序是一个windows服务。当客户端访问某个页面时，我们会挂接信号器OnConnected事件，并注册用户以在我们的数据存储中接收通知。现在，我们存储连接id、它们来自的服务器的IP以及其他一些特定于应用程序的信息。
当服务器进程运行并确定需要向客户端发送消息时，它会使用客户端连接/订阅时捕获的IP构建一个代理（代理被缓存，btw）并发送消息。
现在一切正常。然而，我担心这在负载平衡的情况下不会起作用。我认为如果使用网络套接字没有问题，但我们可以说它又回到了长轮询。难道这不会发生吗：
- 用户A访问页面并通过IP 1.1.1.1的网络服务器X的信号器进行注册
- 另一个长轮询请求来自用户A，但它通过IP为2.2.2.2的web服务器Y
- 服务器进程运行并确定需要发送消息，但它使用用户连接的服务器的IP-1.1.1.1
- 无法将消息发送到客户端
我是不是偏离了这种思路？我试图避免背板，因为每个扩展选项都会给我们带来问题。
简单的答案是肯定的，在负载平衡的环境中，您总是需要背板
较长的版本，您有2台服务器，服务器A和服务器B负载平衡。用户连接到A，用户可以自愿断开连接，也可以通过网络超时或信号R刷新断开连接（这是一个特定的回归，但在未来的版本中仍然可以重新合并，与使用的通信无关），但基本上，用户有时会发现自己"突然"连接到服务器B。现在服务器A将无法向用户发送数据。