Azure Service Bus - 双向通信性能挑战

Question

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

问题似乎是创建和删除这些Subscription对象.开销很大,并且会使应用程序变慢.这并不是说要解决的各种限制,例如主题上的订阅数量不超过2000个.

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

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

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

但是,这仍然没有缩放.似乎AcceptMessageSession()是一个非常昂贵的操作.MessageSession对象是否也应该被缓存并重新使用？每个打开的MessageSession对象是否都使用与服务总线的连接？如果是这样,这是否与订阅的并发连接配额相对应？

非常感谢.我想我们到了那里.Web上的大多数示例代码显示:在客户端上创建Topic(),然后是CreateSubscription(),然后是CreateSubscriptionClient(),然后是BeginReceive(),然后拆除所有对象.我只能说,如果你在现实生活中这样做,你的服务器就会被粉碎,你最快就能连接起来了.

我们需要通过这个东西每秒发出数千个请求,很明显这些对象必须被高速缓存和重用.那么,MessageSession还有另一个要缓存的项目吗？我将获得有趣的缓存,因为我们必须实现一个引用计数机制,其中一次只能给出一个对MessageSession的引用,因为这是针对http请求特定的请求/响应,我们不能有其他订阅者同时使用MessageSession对象.

UPDATE2: 好的,将MessageSession缓存以供重用是不可行的,因为它们只与订阅时的LockDuration一样长.这是一个无赖,因为最大LockDuration是5分钟.这些似乎是短期的pub/sub,而不是长期运行的分布式进程.看起来我们需要回到轮询Azure表.

摘要/评论 我们试图建立Service Bus,因为它具有规模潜力及其持久性和交付语义.但是,似乎有些情况下,它们之间的大量请求/响应不适合它.发布部分工作得很好,并且在后端拥有竞争的消费者是很好的,但是有一个前端请求等待定义的单一消费者响应,根本不能很好地扩展,因为MessageSessions需要太长时间才能完成通过AcceptMessageSession()或BeginAcceptMessageSession()创建,因为它们不适合缓存.

如果有人有另一种观点,我很乐意听到.

Answer 1

此场景是典型的请求/响应，并且是使用会话的良好候选场景。这是另一种相关机制。制作一个简单的请求队列和响应队列。每个 Web 角色线程都会为请求创建一个唯一的 sessionid，并将该值放入代理消息的“ReplyToSessionID”属性中。此外，该线程还使用 sessionid 值在响应队列上调用 AcceptMessageSession ，以便锁定它。代理的消息被发送到请求队列，所有工作角色竞争消息。当辅助角色收到请求时，它会处理该请求，创建响应消息并在响应消息上设置 sessionid 属性 = 请求的replytosessinid。然后，它会被发送到响应队列，并且只会传递到已锁定该会话 ID 的线程。使用会话的详细示例位于此处。这里还有 2 个附加示例，使用队列和主题来实现请求响应关联。