将临时队列用于 Microsoft 服务总线中的请求/响应模式

Question

请求/响应模式涉及向代理发送消息，其中 Reply 属性设置为 QueueName，以向接收者指示返回路径使用的内容。

我看过的所有幻灯片都将回复队列显示为单个频道。当另一端的侦听器知道如何在该队列上正确地代理回复消息时，这可以正常工作。但是，这会使处理无序接收的消息更加痛苦。

我见过为每条发送的消息构建一个新的唯一队列的代码，用于发送回复。然后在接收者发回回复后，原始发送者将回复从队列中取出并删除队列。这似乎可能是很多临时队列的创建/销毁。

我见过的另一个选项是创建一个单一的回复频道作为主题，然后每个原始发件人在该主题上创建一个新订阅，该订阅针对相关性 ID == 发送者 ID 进行过滤。然后当原始发件人收到该回复时，他们会删除该订阅。但是，这似乎又是很多设置/拆卸，只是为了接收消息回复。

• 对于服务总线来说，这两种解决方案是否健康？
• 成百上千的临时队列/订阅在服务总线架构上很常见吗？

Answer 1

对于请求/回复关联，您通常有两种选择：

i) 将消息关联到/来自特定“发件人”或

ii) 基于每条消息关联请求/响应

对于服务总线，有 3 种实现关联的关键方法：

1）每个发件人的单独/唯一队列（比如一个请求队列，然后每个发件人一个响应队列）。这适用于上面有固定数量发件人的选项 i，因为您可以根据上述配额相应地计划容量 ( http://msdn.microsoft.com/en-us/library/ee732538.aspx )

2) 在单个队列中使用会话来关联发送者/消息组。当您有排序和状态管理要求时，会话非常有用，因为它们为您提供严格的排序以及 GetState/SetState 来协调特定消息会话的进度。这可用于上述两个选项。此处提供了有关此的更多信息： -带有代理消息传递的会话示例 -使用会话示例的请求/响应队列

3) 使用Topics/Subscriptions 使用过滤器实现PubSub。同样，如果您想创建每个发件人的订阅，那么您可以使用简单的 SQL 过滤器来实现。使用相关过滤器将允许您为每个订阅添加/删除大量过滤器 (100,000)，这样您就可以在每条消息的基础上进行关联。例如，您有 10 个发件人，然后您创建了一个具有 10 个订阅的主题。每次发送方处理请求时，它都会发送一条消息，同时添加一个相关过滤器包含该消息的correlationid 值的订阅实例。当收到响应时，发送方将删除该消息的过滤器值。因此，每个订阅都可以维护一组过滤器，这些过滤器为发送者期望响应的每条消息指示一个唯一的过滤器。