asp.net-mvc – 可扩展的SignalR Azure – 在哪里放置SignalR,我

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

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

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

当触发器被击中时,我想告诉signalR,“嘿,将此消息发送给以下客户端”以及userIds列表.我假设可以基于userId识别连接的客户端……我假设向客户端发送消息的过程应该在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消息广播的推荐架构是什么？绩效是重中之重,紧随其后的是成本.

奖金问题：

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