JMS应用程序中的最大队列数
考虑一个全新的应用程序，它将具有以下架构
经销商<-->网络<-->发行人
1) 交易商将下订单， 2) 网络对它们进行基本理智处理，然后将它们传递给发行人进行处理， 3) 发行人处理它们并 4）将它们发送回网络（进行一些日志记录） 5) 并将其传回经销商。
我们正在考虑使用队列来实现它。目前我对 JMS 的了解还很有限。我想知道如果我们有 500 多个经销商（比方说），我们是否可以拥有 500 多个传入队列（每个经销商各一个用于传入消息）和相同数量的传出队列（从网络到每个经销商的传出消息各一个）。 。
发行人方面也同样如此 假设有 50 个发行者（因此该侧有 50 + 50 个队列，因此总共 600 个队列）
这种架构是否实用并且在当前的 JEE5 应用程序服务器上受支持。如果这可以在常规 JMS 提供程序（如上面提到的 JEE5 服务器）上实现，我们不想引入任何重型 MQ 实现（如 websphere MQ）？
提前谢谢， 鲁班
Thinking of a brand new application which will have the following architecture
Dealers <--> Network <--> Issuers
1) The Dealers will place orders,
2) Network processes them for basic sanity and then passes them to the Issuers for processing,
3) Issuer processes them and
4) send them back to the network (which does some logging)
5) and passes it back to the Dealer.
We are thinking of implementing it using queues. My knowledge of JMS is limited at this time. I wonder if we had 500+ dealers (lets say) can we have 500+ incoming queues (one each for incoming messages from each dealer) and the same number of outgoing queues (one each for outgoing messages from network to each dealer)...
and the same repeats on the issuers side. lets say there are 50 issuers (so 50 + 50 queues for that side, so in total 600 queues)
Is this kinda architecture practical and supported on current breed of JEE5 application servers. We don't want to introduce any heavy MQ implentations like websphere MQ if this is achievable on a regular JMS providers like the JEE5 servers as mentioned above ?
thx in advance,
Rooban
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
500+队列？哦，我的。我找不到任何东西可以说这是不可能的，但充其量它会很难维护。
如果经销商在您的网络之外，我想他们会通过 HTTP 连接到您，因此每个经销商的输入队列将会消失。您可以使用集群化的 HTTP 监听器来处理传入的请求。
您可能有机会为每个经销商提供一个消息驱动的 Bean 池，但即使每个队列/MDB 对 1MB，也意味着您必须拥有 0.5-1GB 才能拥有队列。这是 Java EE 应用服务器的所有其他要求之上的。
对我来说听起来像是配置/管理噩梦。
您认为为什么需要排队？是“保证交付”、可靠性、异步处理等吸引您的地方吗？
为什么每个经销商都需要自己的队列？每个经销商的处理方式是否不同？
您观察到每个经销商的消息量是多少？您期望什么样的增长？每条消息有多大？消息的有效负载是什么 - XML、JSON 还是其他内容？
在我选择这条路线之前，我会确保我已经探索了几种替代方案，而且都不需要排队。我认为这是可疑的。
500+ queues? Oh, my. I can't find anything to say it's not possible, but at best it'll be very difficult to maintain.
If dealers are outside your network, I'd imagine that they'd connect to you via HTTP, so a input queue per dealer would be out. You'd have clustered HTTP listeners to handle incoming requests.
You might have a chance at a pool of message driven beans for each dealer, but even 1MB per queue/MDB pair would mean you'd have to have 0.5-1GB just to have the queues. That's on top of all the other requirements for your Java EE app server.
Sounds like a configuration/management nightmare to me.
Why do you think you need the queues? Is it 'guaranteed delivery', reliability, asynchronous processing, etc. that attracts you?
Why does each dealer need their own queue? Is the processing different for each dealer?
What kind of message volume per dealer have you observed? What kind of growth do you expect? How large is each message? What is the payload of the message - XML, JSON, or something else?
I would make sure that I had explored several alternatives, none of which required queues, before I took this route. I think it's suspect.