5

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

  • 已创建消息
  • 已提交清单
  • 上市批准

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

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

当触发器被触发时，我想告诉 signalR，“嘿，将此消息发送给以下客户端”以及用户 ID 列表。我假设可以根据 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 消息广播，推荐的架构是什么？ 性能是重中之重，其次是成本。

奖金问题：

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

2 回答 2

2

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

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

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

于 2013-12-16T04:35:53.860 回答
0

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

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

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

于 2013-12-16T14:07:18.543 回答