MQ发布/订阅域特定接口通常比点对点更快吗？

Question

我正在研究使用带有点对点MQ通信的传输层的现有应用程序。

对于每个给定的帐户列表，我们需要检索一些信息。

目前我们有类似的东西与MQ沟通：

responseObject getInfo(requestObject){
    code to send message to MQ
    code to retrieve message from MQ
}

正如您所看到的那样，我们要等到它完成后再继续下一个帐户。 由于性能问题，我们需要重做它。

目前我可以考虑两种可能的情况。

1）在应用程序中创建一堆线程，为每个帐户执行传输适配器。然后从每个任务中获取数据。我更喜欢这种方法，但是一些团队成员认为传输层是更好的地方，我们应该在MQ而不是我们的应用程序上加载额外的负载。

2）返工传输层以使用发布/订阅模型。 理想情况下，我想要这样的事情：

void send (requestObject){
  code to send message to MQ
}

responseObject receive()
{
  code to retrieve message from MQ
}

然后我将在循环中发送请求，然后在循环中检索数据。我们的想法是，虽然后端系统正在处理第一个请求，但我们不必等待响应，而是发送下一个请求。

我的问题是，它会比当前的顺序检索快得多吗？

Answer 1

问题标题将此框架作为P2P和pub / sub之间的选择，但问题正文将其框架化为线程和流水线处理之间的选择。这是完全不同的两件事。

提供的任何代码段都可以轻松地使用P2P或pub / sub来放置和获取消息。该决定不应基于速度，而是基于所讨论的接口是否需要将单个消息传递给多个接收器。如果答案是否定的，那么无论您的应用程序的线程模型如何，您都可能希望坚持使用点对点。

顺便说一下，标题中提出的问题的答案是“不”。使用点对点模型时，消息会立即解析到目标或传输队列，WebSphere MQ会从那里路由它们。使用pub / sub，您的消息将被切换到内部代理进程，该进程将零解析为多个可能的目标。只有在此步骤之后，已发布的消息才会被放置在队列中，在该队列中，对于其余的行程，它将像任何其他点对点消息一样处理。尽管pub / sub通常不会明显慢于点对点，但代码路径更长，因此，在所有其他条件相同的情况下，它会增加更多延迟。

问题的另一部分是关于并行性。您建议启动多个线程或破坏应用程序，以便单独处理请求和回复。第三种选择是运行多个应用程序实例。您可以在设计中组合使用其中的任何一个或全部。例如，您可以启动多个请求线程和多个回复线程，然后让应用程序实例处理多个队列管理器。

这个问题的关键是消息是否具有彼此的亲和力，订单依赖性或创建它们的应用程序实例或线程。例如，如果我使用请求/回复响应HTTP请求，则附加到HTTP会话的线程可能需要是接收回复的线程。但是如果回复是真正的异步，我需要做的就是用响应数据更新数据库，那么拥有单独的请求和回复线程是有帮助的。

在任何一种情况下，动态调高或调低实例数量的能力都有助于管理峰值工作负载。如果仅通过线程完成此操作，那么您的性能可伸缩性将绑定到单个服务器的上限。如果通过在相同或不同的服务器/ QMgr上启动新的应用程序实例来实现这一点，那么您将获得可伸缩性和工作负载平衡。

有关这些主题的更多信息，请参阅以下文章：Mission:Messaging: Migration, failover, and scaling in a WebSphere MQ cluster

此外，转到WebSphere MQ SupportPacs页面，查找适用于您的平台和WMQ版本的Performance SupportPac。这些名称以MP **开头。这些将显示连接的应用程序实例数量变化时的性能特征。

Answer 2

听起来你并没有正确地思考这个问题。无论您使用哪种模式（点对点或发布/订阅），如果您的性能受到慢速后端系统的限制，那么这两种模式都不会有助于加快这一过程。但是，如果您理论上可以一次针对后端系统发出多个请求并期望加速，那么您仍然不关心是否进行点对点或发布/订阅。你真正关心的是同步与异步。

您当前检索数据的方法显然是同步的：您发送请求消息，并等待相应的响应消息。如果您只是在一个方法中连续发送所有请求消息（可能在循环中），那么您可以异步进行通信，然后使用单独的方法（最好在不同的线程上）监视传入的主题以获取响应。这将确保您的代码不再阻止单个请求。 （这大致对应于选项2，但没有pub / sub。）

我认为选项1可能变得非常笨拙，具体取决于您实际需要做多少请求，尽管它也可以在不切换到发布/订阅频道的情况下实现。

Answer 3

重新设计的方法将使用更少的线程。这是否使应用程序更快取决于管理大量线程的开销目前是否会降低您的速度。如果你有少于1000个线程（这是一个非常非常粗略的数量级估计！），我猜它可能不是。如果你有更多，那很可能。