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

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

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

动机：每条消息有两个属性：一个

invocationID

和一个

batchName

。一个批处理由几个调用组成；通过

invocationID

或

batchName

生成消息。在生成消息时，我不知道使用哪种方法

这可以通过选择器实现：

invocationID=42

或

---

…我可以通过使用correlation ID而不是自定义属性来加快其中一个的速度，但我担心另一个仍然会很慢。

这一切都取决于实现。许多JMS提供程序将消息存储在SQL数据库中，以便使用SQL实现选择器。在本例中，您必须查看特定案例是如何映射到SQL的

---

至于WebSphereMQ，选择器实现是O（logn），用于

JMSMessageID=sth

和

JMSCorrelationID=sth

，对于其他的，我没有具体的知识。根据经验，它看起来像是O（n）。

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

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

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

，将按顺序搜索消息。然而，WMQ对

MessageID

和

CorrelID

字段进行索引。信息中心对行为的描述如下：

从队列中选择消息需要WebSphere MQ按顺序 检查队列中的每条消息。消息将被检查，直到 找到与选择条件匹配的消息，或者没有 要检查的更多消息。因此，如果 消息选择用于深队列

基于选择时优化深队列上的消息选择 在JMSCorrelationID或JMSMessageID上，使用 表单JMSCorrelationID=。。。或JMSMessageID=。。。仅供参考 一个财产

此方法在性能上显著提高了 JMSCorrelationID上的选择并提供边际性能 JMSMessageID的改进

---

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

谢谢。您如何知道这些字段的WMQ复杂性？您是否有任何文档链接，或者这是基于分析/猜测吗？@bacar几年前（大约十年前），我参与了一个大量使用WMQ的项目，我们做了一些性能测试。分析表明，复杂性正如我所写的那样。我还没有在任何文档中找到它。好问题！我怀疑这很难得到一个好的答案，但显然对于做出某些架构决策至关重要。谢谢。所有有用的信息，但无论我使用v6还是v7，都可能是线性的-也就是说，虽然v7可以在服务器上而不是客户端上完成工作，但可能效率更高，完成的工作可能仍然需要扫描队列（O（n））上的每一条消息，以找到与选择器匹配的消息。回答很好，感谢链接！选择器本身并不复杂（可能只是在1个属性上相等）-它不一定在correlationid上！我的选择器并不复杂；我已经添加了一些关于我动机的细节，并删除了多路复用的提及，因为它有点不准确。感谢您的澄清！这听起来像是酒吧/酒吧的问题。可以使用管理订阅将消息的一个副本放置在队列上，客户端可以通过CorrelID检索消息。对其他属性感兴趣的客户只需将其作为主题订阅即可。这些可以是动态订阅或持久订阅，但由于选择将在发布时进行评估，因此每个客户机将只获得它感兴趣的消息，并且可以简单地读取其订阅队列FIFO。当然，如果选择在运行时发生更改，这将不起作用。如何“订阅它[队列？]作为主题”，以便“在发布时对选择进行评估”？我不明白你在描述什么功能。每当订阅时，符合条件的程序都会出错

batchName="reconciliation"