asp.net-mvc-3 - Azure 服务总线 - 双向通信性能挑战

Question

我需要在发布者和订阅者之间建立双向通信。这是为了方便前端 MVC3 应用程序定义具有关联过滤器的订阅，然后将消息放置到主题上。最后，MVC3 Controller 在 SubscriptionClient 上调用 BeginReceive()，并等待响应。

问题似乎是这些订阅对象的创建和删除。开销是巨大的，它会减慢应用程序的速度。更不用说要解决的各种限制，例如一个主题的订阅不超过 2000。

在发布者和订阅者之间建立这种双向通信的最佳实践是什么？我们希望 MVC3 应用程序发布一条消息，然后等待对该确切消息的响应(通过 CorrelationId 属性和 CorrelationFilter)。我们已经缓存了 NamespaceManager 和 MessagingFactory，因为它们在资源方面也非常昂贵，而且还因为我们被告知服务总线使用显式配置模型，我们应该在角色启动期间预先创建其中的大部分内容。

因此，这给我们带来了将请求与响应相关联的挑战，以及创建和删除订阅的巨大开销。有什么更好的做法？我们是否应该保留 SubscriptionClient 的缓存，并每次都交换过滤器？其他人都做什么？我需要通过 Web 角色集群获得每秒 5 到 10,000 个 MVC3 请求的请求吞吐量。我们已经在使用 AsyncController 并在 SubscriptionClient 上使用异步 BeginReceive()。在这一点上，似乎是成千上万的订阅的创建和删除正在扼杀系统。

更新 1:
根据此处提供的重要建议，我们更新了此解决方案，以在每个 Web 角色实例上保留 SubscriptionClient 对象的缓存。此外，我们已迁移到面向 MessageSession 的方法。

然而，这仍然不是缩放。似乎 AcceptMessageSession() 是一个非常昂贵的操作。 MessageSession 对象也应该被缓存和重用吗？每个打开的 MessageSession 对象是否都使用到服务总线的连接？如果是，这是否计入订阅的并发连接配额？

非常感谢。我想我们正在到达那里。 Web 上的大多数示例代码显示:在客户端上创建 Topic()，然后是 CreateSubscription()，然后是 CreateSubscriptionClient()，然后是 BeginReceive()，然后是拆除所有对象。我只能说，如果你在现实生活中这样做，你的服务器会被压垮，你会立即最大化连接。

我们需要每秒通过这个东西放置数千个请求，很明显这些对象必须被大量缓存和重用。那么，MessageSession 是另一个要缓存的项目吗？我会很高兴缓存它，因为我们必须实现一个引用计数机制，一次只能给出一个对 MessageSession 的引用，因为这是针对 http 请求特定的请求/响应，我们不能有其他的订阅者同时使用 MessageSession 对象。

更新 2:
好吧，缓存 MessageSession 以供重用是不可行的，因为它们只与 Subscription 上的 LockDuration 一样长。这是一个无赖，因为最大 LockDuration 是 5 分钟。这些似乎适用于短期发布/订阅，而不适用于长时间运行的分布式进程。看起来我们需要重新轮询 Azure 表。

摘要/评论
由于规模潜力及其持久性和交付语义，我们尝试在服务总线上进行构建。但是，似乎存在不适合它的情况，其中包括大量请求/响应。发布部分运行良好，后端有竞争消费者也很好，但前端请求等待定义的单一消费者响应，根本不能很好地扩展，因为 MessageSessions 花费的时间太长通过 AcceptMessageSession() 或 BeginAcceptMessageSession() 创建，因为它们不适合缓存。

如果有人有不同的看法，我很乐意听到。

Answer 1

此场景是典型的请求/响应，是使用 session 的理想选择。这些是另一种相关机制。制作一个简单的请求队列和响应队列。每个 Web 角色线程为请求创建一个唯一的 sessionid，并将该值放入代理消息的“ReplyToSessionID”属性中。此线程也调用了 AcceptMessageSession在具有 sessionid 值的响应队列上，以便将其锁定。代理的消息被发送到请求队列，所有的工作角色都会竞争消息。当工作角色收到一个请求时，它会处理它，创建一个响应消息并在响应消息上设置 sessionid 属性 = 请求的 replytosessinid。然后将其发送到响应队列，并且只会传递到锁定该 session ID 的线程。详细样本using sessions is here .这里有 2 个额外的样本，使用 Queues和 Topics实现请求响应关联。