SignalR 或 Redis pubsub 用于 Azure 上的缩放发布者和缩放订阅者

Question

在我们的应用程序中有一个事件发射器（窗口服务 A）在队列中发射事件。有一个通知服务 (B)（托管在云中的窗口服务），它从队列中读取这些事件并根据配置的规则，向 Web 应用程序 (C) 上的登录用户发送通知。

我们计划在 Web 浏览器和 Web 应用程序 (C) 之间使用 signalR。但是在设置事件发射器（A）和通知服务（B）之间的通信时感到困惑。最初我们也在考虑在那里使用 SignalR。但是有一个问题！如果负载增加，通知服务和网络应用可以横向扩展（拥有多个实例）。

假设有 3 个通知服务实例和 4 个网络服务器实例。现在，SignalR 如何在它们之间工作。每个 Web 服务器都必须为每个通知引擎打开一个 signalR 通道。但这会导致问题：

通知服务和 Web 应用程序之间存在紧密耦合。每当添加一个新的 Web 实例时，它必须形成连接所有可用的通知实例。它下降了，它必须破坏这种联系。通知实例也是如此。

所以，我们正在考虑使用一些 pubsub 而不是 signalR。现在我们可以想到 Redis pubsub。通知服务将消息推送到 Redis，所有 Web 服务器都会订阅它并最终收到消息。

如果我们可以更好地设计，请分享您的想法。

Answer 1

Redis pubsub 不是可靠的消息传递系统。这是一劳永逸。如果某些消息被发送到某个通道并且没有侦听器，则该消息将丢失。

如果您已经在 Azure 中，您的解决方案是 Service Bus 并查看 topics and brokered messages。