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

Question

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

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

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

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

对于服务总线来说，这两种解决方案是否健康？

成百上千的临时队列/订阅在服务总线架构上很常见吗？

Answer 1

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

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

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

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

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

2)在单个队列中使用 session 来关联
发件人/消息组。 session 非常有用，当你有
订购和状态管理要求，因为它们为您提供
严格排序以及 GetState/SetState 来协调
特定消息 session 的进度。这可用于上述两个选项。更多信息
这可以在这里找到:
- Session sample with Brokered messaging
- Request / Response Queue using Sessions samples

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