我有一个场景，大约需要 10 条不同的消息入队，然后出队/处理。一个订阅者需要全部 10 条消息，但另一个订阅者只需要 10 条消息中的 8 条。我试图了解设置这种架构的最佳方法是什么。您是否为每种消息类型创建一个队列，以便订阅者可以订阅相关队列，或者您是否将它们全部转储到同一个队列并忽略与该订阅者无关的消息？我想确保解决方案灵活/可扩展等。
过程：
一如既往地非常感谢这些信息。
--S
从资源的角度来看，创建队列相对“便宜”，而且是的，最好为每个特定目的使用队列，因此在这种情况下，如果可能的话，最好将它们按目标客户端分开。使用队列根据某些标准（相关 ID 或其他东西）有选择地提取消息通常是一个坏主意。消息传递中表现最好的场景是最直接的场景：在消息到达时简单地从队列中拉取消息，而不是选择性地查看和接收。
至于扩展，我不能代表 Websphere MQ 或其他 IBM 产品，但每小时 40-50K 条消息对于 Windows Server 上的 MSMQ 来说并不是特别难处理，所以我认为 IBM 也可以做到这一点。通常瓶颈不是队列平台本身，而是出队和处理单个消息的过程。
好的，根据评论，这是一个可以扩展并且不需要对应用程序进行太多更改的建议。
在生产者方面，我会将消息选择标准复制到消息属性，然后将消息发布到主题。此处需要对应用程序进行的唯一更改是消息属性。如果出于某种原因您不想使用本机功能发布它，您可以在主题上定义别名。该应用程序认为它正在发送消息，但它们实际上是出版物。
在消费者方面，您有几个选择。一种是为每个应用程序创建管理订阅，并在订阅中使用选择器。然后根据选择标准将消息汇集到每个消费者的专用队列。这些应用程序认为它们只是在消费消息。
或者，应用程序可以简单地订阅主题。这使您可以选择在应用程序断开连接时不接收消息的动态订阅（如果实际上您想要的话）或在功能上等同于管理订阅的持久订阅。
此解决方案将轻松扩展到您引用的卷。另一种选择是生产者不使用属性。在这里，消费者应用程序使用所有消息，打开每个消息的有效负载并决定是处理还是忽略消息。在此解决方案中，生产者仍在发布到主题。任何涉及直接排队的解决方案都会迫使生产者知道所有目的地。添加另一个消费者，更改生产者。此外，每个目的地都有一个 PUT。
最坏的情况是生产者放置多条消息，而消费者必须阅读每条消息以决定是否将其忽略。该选项在扩展时可能存在问题，具体取决于选择标准字段在有效负载中的深度。非常长的 XPath 表达式 = 性能差，并且无法调整 WMQ 来弥补它，因为此时延迟都在应用程序中。
最好的情况是，生产者设置一个消息属性并发布。消费者在他们的订阅中选择属性或管理订阅为他们执行此操作。就可伸缩性而言，此解决方案是使用应用程序订阅还是管理订阅并没有任何区别。