适用于Azure上的规模化发布者和规模化订阅者的SignalR或Redis pubsub

Question

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

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

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

通知服务和Web应用程序之间将紧密耦合。 每当添加新的Web实例时，它都必须与所有可用的通知实例建立连接。 而且它失败了，它必须破坏此连接。 通知实例也是如此。

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

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

Answer 1

Redis pubsub不是可靠的消息传递系统。 起火了，算了 。 如果将某些消息发送到某个频道并且没有侦听器，则该消息将丢失。

如果您已经在Azure中，则您的解决方案是Service Bus，并查看主题和代理消息 。