请求/响应模式涉及向代理发送消息，其中回复属性设置为 QueueName，以向接收者指示返回路径使用什么。
我见过的所有幻灯片都将回复队列显示为单个频道。当另一端的侦听器知道如何在该队列上正确代理回复消息时，这可以正常工作。但是，这会使处理乱序接收的消息变得更加痛苦。
我已经看到为每条发送的消息构建一个新的唯一队列以用于发送回复的代码。然后在接收方发回回复后，原始发送方将回复从队列中取出并删除队列。这似乎是很多临时队列的创建/销毁。
我见过的另一种选择是创建一个回复频道作为主题，然后每个原始发件人在该主题上创建一个新订阅，该订阅已针对correlationID == sendersID 进行过滤。然后，当原始发件人收到该回复时，他们会删除该订阅。但是，这似乎又是很多设置/拆卸，只是为了接收消息回复。
对于请求/回复关联，您通常有两个选项：
i) 将消息关联到/来自特定“发件人”或
ii) 基于每条消息关联请求/响应
对于 Service Bus，有 3 种实现关联的关键方法：
1）每个发件人的单独/唯一队列（比如说一个请求队列，然后每个发件人一个响应队列）。这适用于上面有固定数量的发件人的选项 i，因为您可以根据上面提到的配额相应地规划容量 ( http://msdn.microsoft.com/en-us/library/ee732538.aspx )
2）使用单个队列中的会话来关联发件人/消息组。当您有排序和状态管理要求时，会话非常有用，因为它们为您提供严格的排序以及 GetState/SetState 来协调特定消息会话的进度。这可用于上述两个选项。更多信息可在此处获得： -带有代理消息传递的会话示例 -使用会话示例的请求/响应队列
3) 使用主题/订阅通过过滤器实现 PubSub。再次在这里，如果您想为每个发件人创建一个订阅，那么您可以使用简单的 SQL 过滤器来实现。使用关联过滤器将允许您为每个订阅添加/删除大量过滤器（100,000 个），这样您就可以在每条消息的基础上进行关联。例如，您有 10 个发件人，然后您创建一个包含 10 个订阅的主题。每次发送者处理请求时，它都会发送一条消息，同时添加一个相关过滤器包含该消息的相关 ID 值的订阅的实例。当收到响应时，该过滤器值将由该消息的发件人删除。因此，每个订阅都可以维护一组过滤器，这些过滤器指示发送者期望响应的每条消息的唯一过滤器。