在我们的应用程序中，有一个事件发射器（窗口服务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服务器都将订阅它并最终获得消息。
如果我们能够更好地设计，请分享您的想法。
答案 0 :(得分：0)
Redis pubsub 不是一个可靠的邮件系统。它开火并忘记了。如果某些消息被发送到某个频道并且没有收听者，则该消息将丢失。
如果您已经在Azure中，那么您的解决方案为Service Bus，请查看topics and brokered messages。