11

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

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

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

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

invocationID=42

或者

batchName="reconciliation"

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

4

3 回答 3

3

根据文档，消息是按顺序搜索的。然而，WMQ 确实索引MessageID和CorrelID字段。信息中心描述了如下行为：

从队列中选择消息需要 WebSphere MQ 顺序检查队列中的每条消息。检查消息，直到找到与选择标准匹配的消息或没有更多消息要检查。因此，如果在深度队列上使用消息选择，消息传递性能会受到影响。

为了在选择基于jmscorrelationId或jmsmessageid时优化深层队列的消息选择，请使用jmscorrelationId = ...或jmsmessageId = ...的选择字符串，仅引用一个属性。

此方法显着提高了 JMSCorrelationID 上的选择性能，并为 JMSMessageID 提供了边际性能改进。

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

于 2012-11-20T04:12:29.143 回答
2

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

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

于 2012-11-19T00:25:29.643 回答
1

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

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

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

于 2012-11-19T16:03:52.433 回答