当 Web 角色将消息放入存储队列时，它如何轮询特定的相关响应？我希望后端 Worker 角色将消息放入响应队列，目的是让调用者选择响应并从那里开始。
我们的目的是利用队列将一些繁重的处理工作转移到后端 Worker 角色上，以确保 Web 角色的高性能。但是，我们不希望在后端 Worker 完成并响应之前响应 HTTP 请求。
【问题讨论】：
标签： azure queue message-queue azure-storage
我实际上正在做出类似的决定。在我的情况下，我有一个以 Web 角色运行的 WCF 服务，它应该将计算卸载到工作角色。计算出结果后，Web 角色会将答案返回给客户端。
我的基本数据结构知识告诉我，我应该避免使用以非队列方式设计为队列的东西。这意味着应该始终以类似 FIFO 的方式为队列提供服务。所以基本上如果对请求和响应都使用队列，等待向客户端返回数据的线程将不得不等到计算消息位于响应队列的“顶部”，这不是最佳的。如果使用 Azure 表存储响应，线程会轮询消息，从而产生不必要的开销
我相信这个问题的一个可能解决方案是使用请求队列。这可以使用竞争消费者模式，从而实现负载平衡。在发送到此队列的消息上，您在消息上设置correlationId property。对于回复，Azure 服务总线的 pub/sub 部分（“主题”）部分与 correlation filter 一起使用。当您的后端处理了请求时，它会将结果发布到“responseSubject”，并使用原始请求中给出的correlationId。现在，您的客户可以通过使用该相关过滤器调用 CreateSubscrition 来检索此响应（对不起，我显然不能发布两个以上的链接，谷歌它），并且它应该在发布答案时得到通知。请注意，CreateSubscriction 部分应该只在 OnStart 方法中完成一次。然后，您可以对该订阅执行 async BeginRecieve ，当其中一个请求的响应可用时，该角色将在给定的回调中得到通知。 correlationId 将告诉您响应是针对哪个请求的。因此，您的最后一个挑战是将此响应返回给持有客户端连接的线程。
这可以通过使用correlationId（可能是GUID）作为键和响应作为值创建字典来实现。当您的 Web 角色收到请求时，它会创建 guid，将其设置为相关 ID，将其添加到 hashset，将消息发送到队列，然后在 Guid 对象上调用 Monitor.Wait()。然后让主题订阅调用的接收方法将响应添加到字典，然后在同一个 guid 对象上调用 Monitor.Notify()。这会唤醒您的原始请求线程，您现在可以将答案返回给您的客户端（或其他东西。基本上您只是希望您的线程休眠并且在等待时不消耗任何资源）
【讨论】：
Azure 服务总线 上的队列具有更多功能和范例，包括 pub / sub 功能，可以解决跨多个实例处理队列服务的问题。
使用 pub/sub 的一种方法是有一个队列用于请求，一个队列用于响应。每个请求实例还将订阅响应队列，并在标头上使用过滤器，以便它只接收针对它的响应。请求消息当然会包含放置在响应标头中以驱动过滤器的值。
【讨论】：
对于基于服务总线的解决方案，有一些示例可用于使用 Queues 和 Topics (pub-sub) 实现请求/响应模式
【讨论】：
让工作角色继续轮询和处理消息。处理完消息后，在从队列中删除处理后的消息之前，在表存储中添加一个具有所需 corelationId(RowKey) 和处理结果的条目。
然后 WebRoles 只需要使用所需的 correlationId(RowKey) 和 PartitionKey 来查找表
【讨论】：
看看在辅助角色和浏览器客户端之间使用SignalR。因此，您的 Web 角色将消息放入队列并将结果返回给浏览器（类似“等待...”之类的简单操作）并使用 SignalR 将其连接到辅助角色。这样你的网络角色就可以继续做其他事情，而不必等待异步处理的结果，只有浏览器需要。
【讨论】：
Windows Azure 队列没有任何内在特性可以满足您的要求。但是，您可以很容易地自己构建它。在推送到队列中包含消息 ID (GUID)，处理完成后，让工作人员将具有该消息 ID 的新消息推送到响应通道队列中。您的 Web 应用可以轮询此队列以确定给定命令的处理何时完成。
我们已经做了类似的事情，并且正在寻求使用 SignalR 之类的东西来帮助在命令完成时回复客户端。
【讨论】：