在 Microsoft 服务总线中为请求/响应模式使用临时队列答案

【问题标题】：Using Temporary Queues for the Request/Response Pattern in Microsoft Service Bus在 Microsoft 服务总线中为请求/响应模式使用临时队列
【发布时间】：2013-05-07 14:55:50
【问题描述】：

请求/响应模式涉及向代理发送消息，并将回复属性设置为 QueueName，以向接收者指示返回路径使用什么。

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

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

我看到的另一个选项是创建一个回复频道作为主题，然后每个原始发件人创建一个新订阅，该订阅已针对相关 ID == sendersID 进行过滤。然后，当原始发件人收到该回复时，他们会删除该订阅。但是，这似乎需要大量的设置/拆除，只是为了接收消息回复。

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

【问题讨论】：

如果您确实为每条收到的消息创建临时队列/订阅，您需要确保不会遇到配额问题。以下是配额列表：msdn.microsoft.com/en-us/library/ee732538.aspx。每个主题有 2000 个订阅的限制，每个命名空间有 10,000 个队列和主题的限制。

标签： servicebus

【解决方案1】：

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

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

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

对于 Service Bus，有 3 种实现关联的关键方法：

1) 每个发件人的单独/唯一队列（比如单个请求队列和然后每个发件人一个响应队列）。这适用于该选项 i 上面有固定数量的发件人，因为您可以计划根据上述配额相应地获取容量 (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 实例添加到其订阅中，其中包含该消息的相关ID 值。当收到响应时，该过滤器值会被该消息的发件人删除。因此，每个订阅都可以维护一组过滤器，这些过滤器指示发送者期望响应的每条消息的唯一过滤器。

【讨论】：

你对每个选项的缺点有什么看法吗？当我查看您列出的那些时，我的感觉是选项＃2（会话）可能是具有大量请求/响应消息的服务总线的最佳选择，因为它从不创建/删除临时规则/排队。在任何情况下#2 会是一个糟糕的选择吗？也许如果我需要对一堆消息进行负载平衡，我不想要一个队列？
Option2 是一个不错的选择，是的，如果您确实限制为单个队列，那么您就会遇到吞吐量和可用性瓶颈，但您可以通过一组请求和一组响应队列来解决这个问题。仅当您有一个简单的哈希将 SessionId 映射到特定队列时，这才会轻松工作，因为所有相关的消息都应该进入同一个队列和同一个会话。
如果我理解正确的话，我相信 Azure 服务总线现在可以通过分区队列功能为您解决这个问题。目前，如果您将队列创建为分区，它将创建 16 个分区。一条消息只会流经其中一个分区。如果您对超过 1 条消息使用相同的 Session ID，则具有该 Session ID 的所有消息都将通过同一分区进行路由。这允许更高的吞吐量和可用性。
此答案中给出的前 3 个链接已损坏。