JMS 选择器如何随队列深度扩展？答案

【问题标题】：How do JMS selectors scale with queue depth?JMS 选择器如何随队列深度扩展？
【发布时间】：2012-11-06 22:02:55
【问题描述】：

相对于队列深度n，在使用队列中的消息时应用 JMS 选择器的算法时间复杂度是多少？特别是，每次读取是否为线性 (O(n))？它是否依赖于实现（取决于 JMS 提供者），是否依赖于请求的字段？

（如果依赖于实现，我对 Websphere MQ 和 Solace 的行为特别感兴趣，但我欢迎针对任何特定 JMS 提供者的回答，特别是如果您有描述复杂性的文档链接！）。

动机：每条消息都有两个属性：invocationID 和 batchName。一个批处理由多个调用组成。客户希望以两种方式之一来消费消息；通过invocationID 或batchName。在产生消息的那一刻，我不知道它们将通过哪种方法被消耗。

这可以通过选择器来实现：

invocationID=42

或者

batchName="reconciliation"

...我可以通过使用相关 ID 而不是自定义属性来加快其中一个速度，但我担心另一个会保持缓慢。

【问题讨论】：

好问题！我怀疑这很难得到一个好的答案，但显然对于做出某些架构决策至关重要。

标签： java jms ibm-mq

【解决方案1】：

According to the docs，消息按顺序搜索。然而，WMQ 确实索引了 MessageID 和 CorrelID 字段。信息中心将行为描述如下：

从队列中选择消息需要 WebSphere MQ 按顺序检查队列中的每条消息。检查消息，直到找到符合选择条件的消息或没有更多消息要检查。因此，消息传递性能会受到影响，如果消息选择用于深度队列。

在基于选择时优化深度队列上的消息选择在 JMSCorrelationID 或 JMSMessageID 上，使用形成 JMSCorrelationID = ... 或 JMSMessageID = ... 仅供参考一个属性。

这种方法显着提高了性能在 JMSCorrelationID 上进行选择并提供边际性能 JMSMessageID 的改进。

我很想了解更多关于多路复用队列的要求。一个复杂的选择器会影响任何人的实现性能，使用多个开放句柄和更简单的选择器的替代方案与应用程序代码相比使用多个队列没有什么不同。当然，对于 WMQ，动态队列或许多永久定义的队列完全没有问题。很多时候，当我看到这个要求时，它来自使用某些其他传输的商店，在这些传输中，由于定义了许多队列，性能会急剧下降，并且假设在 WMQ 上也是如此。在其他情况下，Pub/Sub 和持久订阅已满足要求。我并不是说这个要求没有有效的案例，只是想知道是什么驱动了它。

【讨论】：

很好的答案，感谢您的链接！选择器本身并不复杂（可能只是在 1 个属性上相等）——它不一定在相关 ID 上！（已被使用）。
我的选择器并不复杂；我添加了一些关于我的动机的细节，并删除了多路复用的提及，因为它有点不准确。
感谢您的澄清！这听起来几乎像一个 Pub/Sub 问题。可以使用管理订阅将消息的一份副本放在队列中，并且客户端可以通过 CorrelID 检索消息。对其他属性感兴趣的客户可以简单地将其作为主题订阅。这些可能是动态订阅或持久订阅，但因为选择会在发布时进行评估，所以每个客户端将只获得它感兴趣的消息，并且可以简单地读取其订阅队列 FIFO。当然，如果选择在运行时发生变化，这将不起作用。
如何“订阅它 [队列？] 作为主题”，以便“在发布时评估选择”？我不明白你在描述什么功能。
无论何时进行订阅，符合条件的消息都会传递到订阅者的队列，该队列可以是预定义的或动态的。订阅本身定义了可以包括主题和消息属性的选择标准。 QMgr 在发布时评估选择标准并将适当的消息传递到正确的队列。由于订阅可以通过管理方式定义，因此使用消息的应用不需要直接订阅，而是可以继续从队列中消费，尽管现在它只接收它感兴趣的消息。

【解决方案2】：

在 WebSphere MQ 版本 7 中，选择器的实现发生了变化。使用 v7 JMS 客户端和 v7 QueueManager，选择处理在 QueueManager 端完成。使用 v6 JMS 客户端（或者实际上是在其迁移中工作的 v7 客户端）模式，所有消息都流向客户端进行处理。如果匹配消息的命中率低，则会浪费大量精力。所以

在 v7 中，处理是在 QueueManager 端完成的，因此只有匹配的消息才会发送到客户端。

请记住，QueueManager 不会像数据库那样维护消息属性的复杂索引。所以选择器越简单越好。

【讨论】：

谢谢。所有有用的信息，但无论我使用 v6 还是 v7，它仍然可能是线性的 - 也就是说，虽然 v7 可以在服务器而不是客户端上完成工作，可能更有效，但完成的工作可能仍然涉及扫描队列中的每条消息(O(n)) 找到一个匹配选择器。

【解决方案3】：

这一切都取决于实施。许多 JMS 提供程序将消息存储在 SQL 数据库中，因此它们可以使用 SQL 来实现选择器。在这种情况下，您必须查看您的特定案例如何映射到 SQL。

至于 WebSphereMQ - JMSMessageID = sth 和 JMSCorrelationID = sth 的选择器实现是 O(log n)，对于其他我没有具体知识。不过根据经验，它看起来像 O(n)。

【讨论】：

谢谢。您如何知道这些字段的 WMQ 复杂性 - 您是否有任何文档的链接，或者这是否基于分析/猜测？
@bacar 几年（大约十年）前，我参与了一个大量使用 WMQ 的项目，我们进行了一些性能测试。分析向我们表明，复杂性正如我所写的那样。我在任何文档中都没有找到它。