当 Web 角色将消息放入存储队列时，它如何轮询特定的相关响应？我希望后端辅助角色将消息放置到响应队列中，其目的是调用者将拾取响应并从那里开始。
我们的目的是利用队列将一些繁重的处理任务转移到后端辅助角色上，以确保 Web 角色的高性能。但是，在后端 Workers 完成并响应之前，我们不希望响应 HTTP 请求。
最佳答案
我实际上正在做出类似的决定。就我而言，我有一个在 Web 角色中运行的 WCF 服务，该服务应该将计算卸载到辅助角色。计算出结果后，Web 角色会将结果返回给客户端。
我的基本数据结构知识告诉我，我应该避免使用以非队列方式设计为队列的东西。这意味着队列应该始终以类似 FIFO 的方式提供服务。因此，基本上，如果对请求和响应都使用队列，则等待将数据返回给客户端的线程将不得不等待，直到计算消息位于响应队列的“顶部”，这不是最佳的。如果使用 Azure 表存储响应，线程会轮询消息，从而产生不必要的开销
我认为解决此问题的可能方法是使用请求队列。这使得能够使用竞争消费者模式，从而实现负载平衡。对于发送到此队列的消息，您设置 correlationId property在消息上。对于回复，Azure 服务总线的发布/订阅部分(“主题”)部分与 correlation filter 一起使用。 。当您的后端处理完请求后，它会使用原始请求中给出的correlationId 将结果发布到“responseSubject”。现在，您的客户可以使用该相关过滤器调用 CreateSubscribtion(抱歉，我显然无法发布两个以上的链接，请通过谷歌搜索)来检索此响应，并且在发布答案时应该会收到通知。请注意，CreateSubscribtion 部分应该只在 OnStart 方法中完成一次。然后，您可以对该订阅执行异步 BeginRecieve，当其请求之一的响应可用时，该角色将在给定的回调中收到通知。 correlationId 将告诉您响应是针对哪个请求的。因此，您的最后一个挑战是将此响应返回给持有客户端连接的线程。
这可以通过创建字典来实现，其中correlationId(可能是GUID)作为键，响应作为值。当您的Web角色收到请求时，它会创建guid，将其设置为correlationId，将其添加为哈希集，将消息发送到队列，然后对Guid对象调用Monitor.Wait()。然后让主题订阅调用的 receive 方法将响应添加到字典中，然后对同一 guid 对象调用 Monitor.Notify()。这会唤醒您原来的请求线程，您现在可以将答案返回给您的客户端(或者其他什么。基本上您只是希望您的线程休眠并且在等待时不消耗任何资源)
关于Azure 存储队列 - 将响应与请求关联起来，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9319239/