JMS 应用程序中的最大队列数答案

【问题标题】：maximum number of queues in JMS applicationJMS 应用程序中的最大队列数
【发布时间】：2011-08-04 08:38:40
【问题描述】：

考虑一个具有以下架构的全新应用程序

经销商网络发行人

1) 经销商将下订单， 2) 网络对它们进行基本处理，然后将它们传递给发行者进行处理， 3) 发行人处理它们并 4）将它们发送回网络（进行一些日志记录） 5) 并将其传回给经销商。

我们正在考虑使用队列来实现它。目前我对 JMS 的了解有限。我想知道我们是否有 500 多个经销商（比方说）我们是否可以有 500 多个传入队列（每个经销商的传入消息各一个）和相同数量的传出队列（从网络到每个经销商的传出消息各一个）.. .

并且在发行方方面重复相同。假设有 50 个发行者（所以那边有 50 + 50 个队列，所以总共有 600 个队列）

这种架构在当前的 JEE5 应用服务器上是否实用且受支持。如果可以在如上所述的 JEE5 服务器等常规 JMS 提供程序上实现，我们不想引入任何重型 MQ 实现，例如 websphere MQ？

提前谢谢，鲁班

【问题讨论】：

【解决方案1】：

超过 500 个队列？天啊。我找不到任何东西可以说这是不可能的，但充其量是很难维护的。

如果经销商在您的网络之外，我想他们会通过 HTTP 连接到您，因此每个经销商的输入队列将不可用。您应该有集群的 HTTP 侦听器来处理传入的请求。

您可能有机会为每个经销商获得一个消息驱动 bean 池，但即使每个队列/MDB 对 1MB 也意味着您必须拥有 0.5-1GB 才能拥有队列。这是对 Java EE 应用服务器的所有其他要求之上的。

对我来说，这听起来像是配置/管理的噩梦。

您认为为什么需要队列？是“保证交付”、可靠性、异步处理等吸引你吗？

为什么每个经销商都需要自己的队列？每个经销商的处理方式是否不同？

您观察到每个经销商的消息量是多少？你期待什么样的增长？每条消息有多大？消息的有效负载是什么 - XML、JSON 或其他？

在我选择这条路线之前，我会确保我已经探索了几个替代方案，其中没有一个需要排队。我认为这是可疑的。

【讨论】：

是的，你提到的功能是我倾向于基于队列的消息传递的原因......经销商--->网络端可以使用一个队列，因为它从经销商到网络是多对一的关系，并且网络必须按照接收到的顺序处理所有消息。但在反面，即网络--->经销商方面，如果网络将消息放在传出队列上，每个经销商如何知道消息是否发给他们？当然，我们不能让发给经销商 1 的消息被经销商 2 提取（并因此从队列中删除）。
——在发行方方面，他们可以使用一个传入和传出队列。 - 网络可以获取这些消息并查看内容以确定它们被发送到的经销商......并放入适当的传出队列。所以我们现在已经显着减少了队列的数量，之前它是 (2* noOfDealers + 2*noOfIssuers) 现在是 (1 + noOfDealers + 1 + 1) - 消息将基于 XML，并且可能最大 10-15k。 - 如果经销商处于可信赖的基于外联网的环境中，他们的客户端程序不能只通过 JNDI 查找我们的队列和连接工厂吗..
- 但即便如此，我们仍在查看与经销商数量相等的队列数（如果有 500 个经销商），服务器上可能需要大约 0.5GB 内存。 - 在这种情况下会推荐哪些其他解决方案？ - 对于这种情况，Websphere MQ 是否会成为更好的平台