请求/响应模式涉及向代理发送消息，并将Reply属性设置为QueueName，以向接收方指示用于返回路径的内容。
我见过的所有幻灯片都将回复队列显示为单个频道。当另一端的侦听器知道如何在该队列上正确地代理回复消息时，这可以正常工作。但是，这可以使得处理收到的消息不再是一种痛苦。
我见过为每个发送的消息构建一个新的唯一队列的代码，用于发送回复。然后，在接收方发回回复后，原始发送方从队列中取回应答并删除队列。这似乎可能是很多临时队列创建/破坏。
我看到的另一个选项是创建一个单独的回复频道作为主题，然后每个原始发件人在该主题上创建一个新的订阅，并针对correlationID == sendersID进行过滤。然后，当原始发件人收到该回复时，他们会删除该订阅。但是，这似乎是很多设置/拆除，只是为了收到消息回复。
答案 0 :(得分：4)
对于请求/回复关联，您通常有两个选项：
i）将消息与特定的＆＃34;发件人＆＃34;进行关联。或
ii）基于每条消息关联请求/响应
对于Service Bus，有3种实现关联的关键方法：
1）每个发件人的单独/唯一队列（比如单个请求队列和 然后每个发件人一个响应队列）。这适用于该选项 因为你可以计划，我上面有固定数量的发件人 根据上述配额相应的容量 （http://msdn.microsoft.com/en-us/library/ee732538.aspx）
2）在单个队列中使用会话来关联 发件人/邮件组。当你有时，会话非常有用 订货和州管理要求，因为他们给你 严格的排序以及GetState / SetState来协调 特定会话消息的进展。这可用于上述两个选项。更多信息 这可以在这里找到： - Session sample with Brokered messaging - Request / Response Queue using Sessions samples
3）使用主题/订阅使用过滤器实现PubSub。在这里，如果你想创建一个每个发件人的订阅，那么你可以使用简单的SQL过滤器来实现。使用相关过滤器将允许您为每个订阅添加/删除大量过滤器（100,000），这样您就可以基于每个消息进行关联。例如，您有10个发件人，然后您创建一个包含10个订阅的主题。每次发件人处理请求时，它都会发送一条消息，同时在其订阅中添加一个correlation filter实例，其中包含该消息的correlationid值。收到响应后，发送方将为该消息删除该过滤器值。因此，每个订阅可以维护一组过滤器，这些过滤器指示发件人期望响应的每个消息的唯一过滤器。