Scalable SignalR + Azure - SignalR 放在哪里，我应该使用 Azure 队列吗？

Question

我正在开发一个具有各种通知类型的应用程序。通知示例：

• 消息已创建
• 清单已提交
• 列表已获批准

我想将所有这些都与 SignalR 联系起来，以便任何连接的客户端都能实时获得更新。

就架构而言 - 现在应用程序完全位于托管在 Azure 网站上的单一解决方案中。这些通知类型中的每一个的触发器都存在于此应用程序中。

当触发触发器时，我想告诉 signalR，“嘿，将此消息发送给以下客户端”以及 userId 列表。我假设可以根据 userId 识别连接的客户端......并且我假设 send message to clients 的进程应该在 Web 应用程序之外执行，以免减慢 MVC 应用程序或风险丢失中断的异步调用中的数据。第一个问题 - 这些假设是否正确？

假设是这样，这意味着我需要一个专门的网络/工作人员角色来向客户发送消息。我可以将消息从我的 Web 应用程序直接传递到这个进程，但是如果进程死了会发生什么？弹性问题使我相信传递消息的正确方法是通过某种队列。第二个问题 - 这是一个有效的思路吗？

假设是这样，这意味着我可以使用一个好的 ol' Azure SQL 数据库作为队列，但似乎有一些专门的（可能更便宜的）服务来处理消息队列，例如：

http://www.windowsazure.com/en-us/develop/net/how-to-guides/queue-service/

第三个问题：这应该用作signalR的队列机制吗？我有兴趣在未来使用Redis进行缓存...... Redis会比队列服务更好还是更差？

最后一个问题：

我试图在这里说明我提出的架构：

我在这里最不清楚的是 MVC 应用程序如何知道何时排队，或者 SignalR 进程如何知道何时广播。 MVC 应用程序是否应该盲目排队，而不关心连接的客户端？这似乎在队列上引入了大量浪费的空间，并在工作角色中浪费了周期，因为只有极少数的客户端会被连接。

我能想到的唯一其他方法是以某种方式让 MVC 应用程序可以看到 SignalR 进程，以查看客户端是否已连接......如果是，则 Enqueue。不过，这让我感到不舒服，因为这意味着我必须为每个被触发的触发器点击图表上的红线，这 - 即使完成异步 - 让我担心性能和可靠性。

对于可扩展、高性能的 SignalR 消息广播，推荐的架构是什么？性能是重中之重，其次是成本。

额外问题：

• 如果某些消息的优先级高于其他消息怎么办？是否应该使用两个队列，其中一个总是在另一个之前被检查？

Answer 1

如果你想定位一些用户，你必须想出一个机制，我可以举个例子，如果任何用户点击一个页面，你可以为那个页面创建一个组，然后推送到该组/该页面中的所有用户。

我不清楚为什么需要队列。通常用户在点击页面或通过加入聊天室等操作时订阅一些事件，并且服务器在适当时使用这些事件/功能推送数据。

为了可扩展性，你可以在不同的服务器上运行 signalr，在这种情况下你应该使用 sql server，或者 service bus 或者 redis 作为背板。

Answer 2

首先，您需要创建一个所有用户都可以连接到的 SignalR 服务器。可以在 Web 角色或辅助角色中创建此 SignalR 服务器。如果您拥有庞大的用户群，那么最好在单独的角色上创建 SignalR 服务器。

然后，无论何时触发触发器并且您想向用户发送消息，您都必须创建一个 SignalR 客户端（.NET 或 javascript），然后连接到 SignalR 服务器。然后您可以将消息发送到 SignalR 服务器，该服务器反过来将广播给所有其他连接的用户。之后，您可以断开与 SignalR 服务器的连接。这样您就不必使用队列来与 SignalR 角色进行通信。

还可以向特定用户发送消息，当他们连接到 SignalR 服务器时，您可以将套接字 ID 及其用户 ID 存储在一个表中（天蓝色表存储应该这样做）。然后使用套接字 id 可以向特定用户发送消息。