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

问题标题将其作为P2P和pub / sub之间的选择，而问题正文将其作为在线程处理和流水线处理之间的选择。这是两件完全不同的事情。 提供的任何代码片段都可以使用P2P或pub / sub轻松放置和获取消息。该决定不应该基于速度，而应该取决于所讨论的接口是否需要将单个消息传递给多个接收者。如果答案是否定的，那么无论您的应用程序的线程模型如何，您都可能希望坚持点对点。 并且，顺便说一句，标题中提出的问题的答案是\“ no。\”。当您使用点对点模型时，消息立即解析到目的地或传输队列，然后WebSphere MQ从那里路由它们。使用pub / sub，您的消息将传递到内部代理程序，该程序将零解析为许多可能的目的地。仅在此步骤之后，才将已发布的消息放入队列中，在此过程的其余过程中，该消息将像其他任何点对点消息一样进行处理。尽管pub / sub通常不会比点对点慢很多，但是代码路径更长，因此，在所有其他条件相同的情况下，它将增加更多的延迟。 问题的另一部分是关于并行性。您建议要么分解多个线程，要么分解该应用程序，以便分别处理请求和答复。第三种选择是运行多个应用程序实例。您可以在设计中组合任何或所有这些。例如，您可以启动多个请求线程和多个答复线程，然后让应用程序实例针对多个队列管理器进行处理。 这个问题的关键是消息之间是否相互关联，对依赖关系进行排序，对创建它们的应用程序实例或线程是否具有关联。例如，如果我用请求/答复来响应HTTP请求，则附加到HTTP会话的线程可能需要是接收答复的线程。但是，如果回复确实是异步的，而我需要做的只是用响应数据更新数据库，那么拥有单独的请求和回复线程将很有帮助。 无论哪种情况，动态地增加或减少实例数量的能力都有助于管理高峰工作负载。如果仅通过线程完成此操作，那么您的性能可伸缩性将受限于单个服务器的上限。如果通过在相同或不同的服务器/ QMgr上扩展新的应用程序实例来实现此目的，那么您将获得可伸缩性和工作负载平衡。 请参阅以下文章，以获取有关这些主题的更多想法：任务：消息传递：WebSphere MQ集群中的迁移，故障转移和扩展 另外，转到WebSphere MQ SupportPacs页面，并为您的平台和WMQ版本查找Performance SupportPac。这些是名称以MP **开头的名称。随着连接的应用程序实例数量的变化，这些将向您显示性能特征。     

听起来好像您在考虑正确的方法。无论使用哪种模型（点对点或发布/订阅），如果您的性能受到缓慢的后端系统的限制，那么两者都将无助于加快流程。但是，如果理论上您可以在后端系统上一次发出多个请求，并且希望看到速度加快，那么您仍然不在乎是进行点对点还是发布/订阅。您真正关心的是同步与异步。 您当前检索数据的方法显然是同步的：发送请求消息，然后等待相应的响应消息。如果您只用一种方法简单地连续发送所有请求消息（可能是循环发送），然后又有一个单独的方法（最好在不同的线程上）监视传入主题的响应，则可以异步进行通信。这样可以确保您的代码不会再因单个请求而阻塞。 （尽管没有pub / sub，这大致对应于选项2。） 我认为选项1可能会变得毫无用处，具体取决于您实际需要发出多少请求，尽管也可以在不切换到发布/订阅通道的情况下实现它。     

重新设计的方法将使用更少的线程。这是否会使应用程序更快取决于当前管理大量线程的开销是否在拖慢您的速度。如果您的线程数少于1000（这是一个非常非常粗略的数量级估计！），我想可能不是。如果您拥有的不止于此，那可能就可以了。