Signalr 服务器广播实现中的信号器扩展/背板-是否会导致向客户端发送重复消息？

SignalR文档表明，scaleout/backplane在服务器广播类型的加载/实现中运行良好。然而，我怀疑在纯服务器广播的情况下，它会导致重复的消息被发送到客户端。考虑下面的场景：

我有两个hub实例，它们位于我的web服务器场上负载平衡器后面的两个web服务器上

每台服务器上的中心都实现了一个用于数据库轮询的计时器，以获取一些更新并按主题id分组广播给客户端

组/主题的客户机可能在两台服务器之间划分

两个中心实例都将从数据库中获取相同或重叠的更新

现在，由于每个集线器都通过背板向客户端发送更新，它是否会导致向客户端发送重复的更新

---

请提出建议。

问题不在于SignalR，而在于您的数据中心内的数据库轮询。背板正确地处理广播复制，但如果您为集线器增加了另一项责任，则情况就不同了。这是复制消息的部分，而不是信号器，因为现在有N个轮询器在所有服务器实例上进行广播

例如，您可以将该逻辑从集线器中删除到其他地方，让服务器应用程序的一个实例使用这个新的部分，以便通过轮询生成消息，可能使用一个配置来决定哪一个。这样，您将只从那个里发送消息，信号器的背板将负责复制。这只是一个非常基本的建议，可以做不同的事情，但关键是你的民意调查不应该被复制，这与Signal没有直接关系

---

同样，投票可能不是处理您的情况的最佳方式，但这将回答一个不同的问题。

为什么您需要时间？？您可以使用sql更新通知程序或手动触发方法。你可以看看这个@AnikIslamAbhi：我的应用程序是实时通信的，更新频率很高，我不想被更新通知程序或触发器淹没。相反，我想要的是一个间隔池，用于获取更新并向客户端发送更新，而不会导致从接收端到数据库的大量连接。所谓手动触发，我的意思是在用户操作时通知，如用户插入内容。然后将更新通知发送给每个我已经实现了类似的东西的人。检查我提供的githublink@Anik-Islam Abhi：“手动触发器”使其成为“用户事件驱动”或“客户端到客户端”场景/应用程序，而不是“服务器广播”。我关心的是文档中说，在“客户端到客户端”的情况下，背板可能会成为瓶颈。那是有道理的。实际上我有这个想法，但我担心如果指定负责获取和广播更新的服务器出现故障，那么应用程序就会停止。这可能意味着实现单独的逻辑来监视第一台服务器的活动，并跟踪第二台服务器的活动，以便在第一台服务器停机时轮到它来承担额外的责任。我可能还可以实现客户端到客户端的场景，而不是广播。但我好奇地想知道，如果必须将广播责任仅分配给一台服务器，那么在web场中使用SiganlR背板的广播场景在哪里真正有意义？这对于任何客户端发起的广播都是有意义的（想想一个聊天系统，其中一个用户想对每个人说“你好”）。如果您有一个不只是做信号器的服务器，并且其中任何一个都可以在负载平衡器后面执行传统的HTTP，那么这也是有意义的，在这种情况下，您可能会有一个HTTP POST命中一个特定的服务器并生成广播。您遇到的问题是针对您的情况的，您的评论是有意义的，但还有许多其他情况下，广播是“从系统外部”启动的，并且它们与背板配合得很好。我认为您所说的客户端启动的广播（例如聊天）是“客户端到客户端”或“用户事件驱动”的场景，而不是“服务器广播”场景。参考：我的应用程序实际上是一个类似的用户事件驱动场景，包括聊天以及其他核心功能，该功能可以生成从少数用户到其他用户组的非常高频率的更新。我很关心文档（参考上面的链接）说背板可能是客户机到客户机场景中的瓶颈。因此我考虑将其实现为服务器广播，其中消息/更新不会直接发送到目标客户机/组&从源客户机接收时立即发送，但服务器应通过定期轮询来控制到目标的传输数据库更新。到目前为止，我认为在信号广播场景中，web场只会帮助增加服务器的最大连接容量和负载，但它不能在节点出现故障时提供现成的冗余。