如何实现消息队列解决方案

Question

我有一个场景，大约 10 条不同的消息需要入队，然后出队/处理。一个订阅者需要全部 10 条消息，但另一个订阅者只需要 10 条消息中的 8 条。我试图了解设置这种架构的最佳方法是什么。您是否为每种消息类型创建一个队列，以便订阅者可以订阅相关队列，或者您是否将它们全部转储到同一个队列并忽略与该订阅者无关的消息？我想确保解决方案灵活/可扩展等。

流程：

1. 10 条不同的 xml 消息将排队到 IBM WebSphere MQ 服务器。
2. 我们将使用 .Net（很可能是 WCF，因为 WebSphere MQ 7.1 添加了 WCF 支持）
3. 我们会将消息出列并将它们加载到另一个后端数据库（很可能是 SQL Server）。
4. 解决方案需要很好地扩展，因为我们将处理非常大量的消息并且这可能会增长（可能 40-50,000/小时）。至少对我们来说很大。

一如既往地非常感谢您提供的信息。

--S

Answer 1

好的，根据 cmets，这是一个可以扩展的建议，不需要对应用程序进行太多更改。

在生产者方面，我会将消息选择标准复制到消息属性，然后将消息发布到主题。此处需要对应用程序进行的唯一更改是消息属性。如果由于某种原因您不想使用本机功能发布它，您可以在主题上定义别名。该应用认为它是在发送消息，但它们实际上是出版物。

在消费者方面，您有几个选择。一种是为每个应用程序创建管理订阅并在订阅中使用选择器。然后，根据选择标准，将消息汇集到每个消费者的专用队列。这些应用认为它们只是在消费消息。

或者，应用可以简单地订阅主题。这使您可以选择在应用断开连接时不接收消息的动态订阅（如果您确实想要的话）或在功能上等同于管理订阅的持久订阅。

此解决方案将轻松扩展到您引用的卷。另一种选择是生产者不使用属性。在这里，消费者应用程序使用所有消息，打开每个消息的有效负载并决定是处理还是忽略消息。在此解决方案中，生产者仍在发布到主题。任何涉及直接排队的解决方案都会迫使生产者知道所有目的地。添加另一个消费者，更改生产者。此外，每个目的地都有一个 PUT。

最坏的情况是生产者放置多条消息，而消费者必须阅读每条消息以决定是否将其忽略。该选项在扩展时可能存在问题，具体取决于选择标准字段在有效负载中的深度。很长的 XPath 表达式 = 性能不佳，并且无法调整 WMQ 来弥补它，因为此时延迟都在应用程序中。

最好的情况，生产者设置一个消息属性并发布。消费者在他们的订阅中选择属性或管理订阅为他们执行此操作。就可扩展性而言，此解决方案是使用应用程序订阅还是管理订阅并没有任何区别。

Answer 2

从资源的角度来看，创建队列相对“便宜”，而且是的，最好为每个特定目的使用队列，因此在这种情况下，如果可能的话，最好通过目标客户端将它们分开。使用队列根据某些标准（相关 ID 或其他东西）有选择地提取消息通常是一个坏主意。消息传递中表现最好的场景是最直接的场景：在消息到达时简单地从队列中拉取消息，而不是选择性地查看和接收。

至于扩展，我不能代表 Websphere MQ 或其他 IBM 产品，但每小时 40-50K 条消息对于 Windows Server 上的 MSMQ 来说并不是特别难处理，所以我认为 IBM 可以做到这一点好吧。通常瓶颈不是队列平台本身，而是出队和处理单个消息的过程。