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

Question

我正在开发使用传输层和点对点 MQ 通信的现有应用程序。

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

目前我们有这样的东西来与 MQ 通信:

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

如您所见，我们等到它完全完成后再继续下一个帐户。由于性能问题，我们需要对其进行返工。

目前我可以想到 2 种可能的情况。

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

2) 重做传输层以使用发布/订阅模型。理想情况下，我想要这样的东西:

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

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

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

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

Answer 1

问题标题将此定义为 P2P 和发布/订阅之间的选择，但问题正文将其定义为线程处理和流水线处理之间的选择。这是两个完全不同的东西。

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

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

问题的另一部分是关于并行性的。您建议要么启动多个线程，要么拆分应用程序，以便分别处理请求和回复。第三种选择是运行多个应用程序实例。您可以在您的设计中组合任何或所有这些。例如，您可以启动多个请求线程和多个回复线程，然后让应用程序实例针对多个队列管理器进行处理。

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

无论哪种情况，动态增加或减少实例数量的能力都有助于管理峰值工作负载。如果这是单独使用线程来完成的，那么您的性能可伸缩性将受到单个服务器的上限。如果这是通过在相同或不同的服务器/QMgr 上启动新的应用程序实例来实现的，那么您将同时获得可扩展性和工作负载平衡。

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

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