我正在开发一个具有各种类型通知的应用程序 . 通知示例：
-
已创建消息
-
列出已提交
-
已批准上市
我想将所有这些都绑定到SignalR，以便任何连接的客户端实时获得更新 .
就架构而言 - 现在该应用程序完全位于Azure网站上托管的单一解决方案中 . 每种通知类型的触发器都存在于此应用程序中 .
当触发器被命中时，我假设's possible to identify connected clients based on userId... and I'假设应该在Web应用程序之外执行 send message to clients ，以便不会减慢MVC应用程序或在丢失的异步调用中丢失数据的风险 . 第一个问题 - are these assumptions correct?
假设如此，这意味着我需要像专用的web / worker角色那样向客户端发送消息 . 我可以将来自我的Web应用程序的消息直接传递给此过程，但是如果该过程死亡会发生什么？弹性问题让我相信传递消息的正确方法是通过某种队列 . 第二个问题 - is this a valid train of thought?
假设是这样，这意味着我可以使用一个好的'Azure SQL数据库作为队列，但似乎有一些专门的（也许更便宜的）服务来处理消息队列，例如：
http://www.windowsazure.com/en-us/develop/net/how-to-guides/queue-service/
第三个问题： Should this be used as a queueing mechanism for signalR? 我有兴趣在将来使用Redis进行缓存...... Redis会比队列服务更好还是更差？
最后的问题：
我试图在这里说明我提出的架构：
我在这里最不清楚的是MVC应用程序将如何知道何时排队，或者SignalR进程将如何知道何时进行广播 . MVC应用程序应该盲目排队，而不关心连接的客户端吗？这似乎在队列中引入了大量浪费的空间，并且在工作者角色中浪费了周期，因为很少一部分客户端将被连接 .
我能想到的唯一其他方法是以某种方式让MVC应用程序可以看到SignalR进程，以查看客户端是否已连接......如果是，则为Enqueue . 这让我感到不舒服，因为这意味着我必须在图表上为每个被击中的触发器击中红线，即使完成异步 - 让我担心性能和可靠性 .
What is the recommended architecture for scalable, performant SignalR message broadcasting? 业绩是重中之重，紧随其后的是成本 .
奖金问题：
- 如果某些消息的优先级高于其他消息怎么办？是否应该使用两个队列，其中一个总是在另一个队列之前被检查？
2 回答
如果你想针对一些用户，你将不得不想出一个机制，我可以举一个例子，如果有任何用户点击一个页面，你可以为该页面创建一个组并推送到所有用户该组/该页面中的用户 .
我不清楚为什么你需要队列 . 通常用户在点击页面时会订阅某些事件，或者通过加入聊天室等某些操作来订阅，服务器会在适当的时候使用这些事件/功能来推送数据 .
为了扩展，您可以在不同的服务器上运行signalr，在这种情况下，您应该使用sql server，或者使用service bus或redis作为背板 .
首先，您需要创建一个所有用户都可以连接到的SignalR服务器 . 可以在Web角色或辅助角色中创建此SignalR服务器 . 如果您拥有庞大的用户群，那么最好在单独的角色上创建SignalR服务器 .
然后，只要触发器被触发并且您想要向用户发送消息，就必须创建SignalR客户端（.NET或javascript），然后连接到SignalR服务器 . 然后您可以将消息发送到SignalR服务器，然后信号服务器将广播给所有其他连接的用户 . 之后，您可以断开与SignalR服务器的连接 . 这样您就不必使用队列与SignalR角色进行通信 .
此外，为了向特定用户发送消息，您可以在连接到SignalR服务器时将套接字ID及其用户ID存储在表（azure表存储应该执行）中 . 然后使用套接字ID，您可以向特定用户发送消息 .