确定 Signalr 背板是否必要

Question

我无法确定在我的场景中是否需要使用 Signalr 背板。不幸的是，我无法获得我需要自己测试的测试环境，所以我来这里;）

在我的场景中，我们使用信号器与来自服务器应用程序的特定客户端（使用连接 ID）进行通信，这是一个 Windows 服务。当客户端访问某个页面时，我们会挂接到信号器 OnConnected 事件并注册用户以在我们的数据存储中接收通知。现在我们存储连接 ID、它们来自的服务器的 IP 以及其他一些特定于应用程序的信息。

当服务器进程运行并确定它需要向客户端发送消息时，它使用客户端连接/订阅时捕获的 IP 构造一个代理（代理被缓存，顺便说一句）并发送消息。

现在工作正常。但是，我担心这在负载平衡的情况下不起作用。我在想如果使用网络套接字没有问题，但可以说它回退到长轮询。这不可能发生吗：

• 用户 A 访问该页面并通过来自 IP 1.1.1.1 的 Web 服务器 X 的 Signalr 进行注册
• 另一个长轮询请求来自用户 A，但它通过 IP 2.2.2.2 的 Web 服务器 Y
• 服务器进程运行并确定它需要发送消息，但它使用用户连接的服务器的IP - 1.1.1.1
• 消息无法发送到客户端

我的这种想法是否离题了？我试图避免使用背板，因为每个横向扩展选项都给我们带来了问题。

Answer 1

简短的回答是肯定的，在负载平衡的环境中您总是需要一个背板

较长的版本，您有 2 台服务器服务器 A 和 B 负载平衡。用户连接到 A ，用户可以自愿断开连接或通过网络超时，或通过 signalR 刷新（有几个关于此的错误打开，这是一定的回归，但仍然可以在未来的版本中重新合并，与使用哪种通信无关）但基本上用户有时会发现自己“突然”连接到服务器 B。现在服务器 A 将无法向用户发送数据。