2

我正在研究使用传输层和点对点 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
}

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

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

4

3 回答 3

3

问题标题将此定义为 P2P 和 pub/sub 之间的选择，但问题主体将其定义为线程处理和流水线处理之间的选择。这是两个完全不同的东西。

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

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

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

这个问题的关键是消息是否相互关联，是否对依赖关系排序或与创建它们的应用程序实例或线程有关联。例如，如果我使用请求/回复来响应 HTTP 请求，那么附加到 HTTP 会话的线程可能需要是接收回复的线程。但是，如果回复是真正异步的并且我需要做的就是使用响应数据更新数据库，那么拥有单独的请求和回复线程会很有帮助。

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

有关这些主题的更多想法，请参阅以下文章：任务：消息传递：WebSphere MQ 集群中的迁移、故障转移和扩展

Also, go to the WebSphere MQ SupportPacs page and look for the Performance SupportPac for your platform and WMQ version. These are the ones with names beginning with MP**. These will show you the performance characteristics as the number of connected application instances varies.

于 2011-05-18T11:36:09.573 回答
1

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

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

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

于 2011-05-17T17:36:26.490 回答
0

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

于 2011-05-17T17:34:34.823 回答