максимальное количество очередей в приложении JMS - PullRequest
Новая
       39

максимальное количество очередей в приложении JMS

0 голосов
/ 13 апреля 2011

Думая о совершенно новом приложении, которое будет иметь следующую архитектуру

Дилеры <-> Сеть <-> Эмитенты

1) Дилеры будут размещать заказы, 2) Сеть обрабатывает их для базового здравого смысла и затем передает их Эмитентам для обработки, 3) Эмитент обрабатывает их и 4) отправить их обратно в сеть (что делает некоторые записи) 5) и передает его Дилеру.

Мы думаем о реализации этого с использованием очередей. В настоящее время мои знания о JMS ограничены. Интересно, если бы у нас было более 500 дилеров (скажем так), можем ли мы иметь более 500 входящих очередей (по одной для входящих сообщений от каждого дилера) и такое же количество исходящих очередей (по одной для исходящих сообщений из сети каждому дилеру) .. .

и то же самое повторяется на стороне эмитента. скажем, есть 50 эмитентов (то есть 50 + 50 очередей для этой стороны, то есть всего 600 очередей)

Является ли эта своего рода архитектура практичной и поддерживается на современных типах серверов приложений JEE5. Мы не хотим вводить какие-либо тяжелые внедрения MQ, такие как websphere MQ, если это достижимо на обычных провайдерах JMS, таких как серверы JEE5, как упомянуто выше?

спасибо заранее, Rooban

1 Ответ

1 голос
/ 13 апреля 2011

500 + очередей?О мойЯ не могу найти ничего, чтобы сказать, что это невозможно, но в лучшем случае это будет очень трудно поддерживать.

Если дилеры находятся за пределами вашей сети, я бы предположил, что они подключатся к вам через HTTP, поэтому входная очередь для каждого дилера будет отсутствовать.Для обработки входящих запросов у вас были бы кластеризованные HTTP-прослушиватели.

Возможно, у вас есть шанс получить пул управляемых сообщениями компонентов для каждого дилера, но даже 1 МБ на пару очередь / MDB означают, что вам потребуется0.5-1ГБ просто для очередей.Это в дополнение ко всем остальным требованиям для вашего сервера приложений Java EE.

Для меня это похоже на кошмар конфигурации / управления.

Почему вы думаете, что вам нужны очереди?Вас привлекает «гарантированная доставка», надежность, асинхронная обработка и т. Д.

Почему каждому дилеру нужна своя очередь?Различна ли обработка для каждого дилера?

Какой объем сообщений у каждого дилера вы наблюдали?Какой рост вы ожидаете?Насколько велико каждое сообщение?Какова полезная нагрузка сообщения - XML, JSON или что-то еще?

Я бы позаботился о том, чтобы изучить несколько альтернатив, ни одна из которых не требовала очередей, прежде чем идти по этому маршруту.Я думаю, что это подозрительно.

...