可扩展的SignalR + Azure - 在哪里放置SignalR,我应该使用Azure队列吗？

Question

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

• 消息已创建
• 列出已提交
• 上市批准

我想将所有这些都绑定到SignalR,以便任何连接的客户端实时获得更新.

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

当触发器被击中时,我想告诉signalR,"嘿,将此消息发送给以下客户端"以及userIds列表.我假设可以基于userId来识别连接的客户端......我假设send message to clients应该在Web应用程序之外执行该过程,以便不会减慢MVC应用程序或者丢失数据的风险打破异步调用.第一个问题 - 这些假设是否正确？

假设如此,这意味着我需要像专用的web/worker角色那样向客户端发送消息.我可以将来自我的Web应用程序的消息直接传递给此过程,但是如果该过程死亡会发生什么？弹性问题让我相信传递消息的正确方法是通过某种队列.第二个问题 - 这是一个有效的思路吗？

假设是这样,这意味着我可以使用一个好的'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，或服务总线或redis作为背板。