如何实现消息队列解决方案
本文关键字：消息 队列 解决方案 实现 何实现 | 更新日期: 2023-09-27 18:12:42
我有一个场景，其中大约有10个不同的消息需要加入队列，然后退出队列/处理。一个订阅者将需要所有10条消息，但另一个订阅者将只需要10条消息中的8条。我正在尝试理解设置这种架构的最佳方式是什么。您是为每种消息类型创建一个队列，以便订阅者可以只订阅相关的队列，还是将它们全部转储到同一个队列中，并忽略与该订阅者不相关的消息?我想确保解决方案是灵活的/可扩展的，等等。
过程:
- 10个不同的xml消息将被排队到IBM WebSphere MQ服务器。我们将使用。net(很可能是WCF，因为WebSphere MQ 7.1已经添加了WCF支持)
- 我们将从队列中取出消息并将其加载到另一个后端数据库(很可能是SQL Server)。
- 解决方案需要很好地扩展，因为我们将处理非常大量的消息，并且这可能会增长(可能是40-50,000/小时)。至少对我们来说是一大笔钱。
——S
从资源的角度来看，创建队列相对"便宜"，另外，最好为每个特定目的使用一个队列，所以在这种情况下，如果可能的话，根据目标客户机将它们分开可能更好。使用队列根据某些标准(相关性ID或其他一些东西)有选择地提取消息通常是一个坏主意。消息传递中表现最好的场景是最直接的:在消息到达时简单地从队列中拉出消息，而不是有选择地查看和接收消息。
至于可伸缩性，我不能说Websphere MQ或其他IBM产品，但是对于Windows Server上的MSMQ来说，每小时40-50K消息的处理并不特别困难，所以我认为IBM也可以做到这一点。通常瓶颈不是队列平台本身，而是脱离队列和处理单个消息的过程。
好的，根据评论，这里有一个建议，可以扩展，不需要对应用程序进行太多更改。
在生产者端，我将消息选择标准复制到消息属性，然后将消息发布到主题。这里需要对应用程序进行的唯一更改是message属性。如果出于某种原因不想让它使用本机功能发布，可以在主题上定义别名。应用程序认为它在发送消息，但它们实际上是出版物。
在消费者方面，你有几个选择。一种是为每个应用程序创建管理订阅，并在订阅中使用选择器。然后，根据选择标准将消息汇集到每个消费者的专用队列中。应用程序认为它们只是在消费消息。
或者，应用程序可以简单地订阅主题。这为您提供了动态订阅的选项，当应用程序断开连接时不接收消息(如果实际上您想要的话)或持久订阅，在功能上等同于管理订阅。
此解决方案可以轻松扩展到您引用的卷。另一种选择是生产者不使用属性。在这里，使用者应用程序使用所有消息，打开每个消息的有效负载，并决定是处理还是忽略消息。在此解决方案中，生产者仍然向主题发布。任何涉及直接排队的解决方案都迫使生产者知道所有目的地。增加一个消费者，改变生产者。此外，每个目的地都有一个PUT。
最糟糕的情况是生产者放置多个消息，而消费者必须阅读每一条消息以决定是否要忽略它。该选项可能存在扩展问题，具体取决于选择标准字段在有效负载中的深度。非常长的XPath表达式=较差的性能，并且没有办法调优WMQ来弥补它，因为此时延迟都在应用程序中。
最好的情况是，生产者设置消息属性并发布。消费者在其订阅或管理订阅中选择属性。就可伸缩性而言，该解决方案是使用应用程序订阅还是管理订阅没有任何区别。