在我们的应用程序中，有一个事件发射器(窗口服务 A)在队列中发射事件。有一个通知服务 (B)(云中托管的窗口服务)从队列中读取这些事件，并根据配置的规则向 Web 应用程序 (C) 上的登录用户发送通知。
我们计划在 Web 浏览器和 Web 应用程序 (C) 之间使用 signalR。但对设置事件发射器 (A) 和通知服务 (B) 之间的通信感到困惑。最初我们也考虑在那里使用 SignalR。但是有一个问题!如果负载增加，通知服务和 Web 应用程序可以横向扩展(具有多个实例)。
假设有 3 个通知服务实例和 4 个网络服务器实例。现在，SignalR 如何在它们之间工作。每个 Web 服务器都必须为每个通知引擎打开一个 signalR channel 。但这会导致问题:
通知服务和 Web 应用程序之间将紧密耦合。每当添加新的 Web 实例时，它都必须形成连接所有可用的通知实例。它下降了，它必须破坏这种联系。通知实例也是如此。
因此，我们正在考虑使用一些 pubsub 而不是 signalR。现在我们可以想到Redis pubsub。通知服务会将消息推送到 Redis，所有 Web 服务器都会订阅它并最终收到消息。
如果我们可以设计得更好，请分享您的想法。
最佳答案
Redis pubsub 不是可靠的消息传递系统。这是即发即弃。如果一些消息被发送到某个 channel 并且没有监听器，则消息丢失。
如果您已经在 Azure 中，您的解决方案是 Service Bus看看topics and brokered messages .
关于c# - SignalR 或 Redis pubsub 用于 Azure 上的缩放发布者和缩放订阅者，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/34070938/