Советы по MoM и большие сообщения

Question

Я разрабатываю систему, которая будет использовать jms и некоторое программное обеспечение для обмена сообщениями (я склоняюсь к ActiveMQ) в качестве промежуточного программного обеспечения.Там будет менее 100 агентов, каждый из которых будет отправлять не более 5000 сообщений в день через очередь.

Полезная нагрузка для каждого сообщения будет около 100 байт каждое.Я ожидаю, что примерно половина (2500) сообщений будет кластеризоваться около полуночи, а другая половина будет несколько равномерно распределена в течение дня.Цифры, приведенные выше, находятся на более высоком уровне, чем я ожидаю.(Да, я, вероятно, съест это утверждение в ближайшем будущем).

Существует один тип сообщений, в котором полезная нагрузка будет значительно больше, скажем, в диапазоне 5-50 МБ.Эти сообщения будут отправляться только несколько раз в день от каждого агента.

Мои вопросы: Это вызовет какие-либо проблемы или совершенно нормально отправлять большие объемы данныхчерез очередь сообщений?

Например, уменьшит ли он пропускную способность (меньшие по очереди сообщения) при работе с сообщениями большего размера?

Или очередь сообщений захлебнется большими сообщениями?

Или следуетЯ подхожу к этому по-другому, скажем, отправив местоположение данных через jms, и пусть конечный получатель заберет данные в другом месте?(Я надеялся, что у меня не будет особого случая из-за связи, проблем безопасности и дополнительной конфигурации).

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

Отредактировано: Я принял Андреса действительно потрясающий ответ.Продолжайте публиковать советы и мнения, я буду поддерживать все полезное.

Answer 1

Большие сообщения определенно окажут влияние, но упомянутые здесь размеры (5-50 МБ) должны управляться любым приличным сервером JMS.

Однако учтите следующее.При обработке конкретного сообщения все сообщение считывается в память.Таким образом, если каждый из 100 агентов отправляет сообщение размером 50 МБ в другую очередь примерно в одно и то же время или в разное время, но для удаления сообщений требуется много времени, вы можете столкнуться с ситуацией, когда вы пытаетесь поместить сообщения объемом 5000 МБ в память.Я сталкивался с подобными проблемами с сообщениями 4MB с ActiveMQ в прошлом, однако было отправлено больше сообщений, чем цифры, упомянутые здесь.Если все сообщения отправляются в одну (постоянную) очередь, это не должно быть проблемой, поскольку в памяти должно находиться только обрабатываемое сообщение.

Так что это зависит от вашей настройки.Если теоретический верхний предел в 5000 МБ является управляемым для вас (и помните о 32-разрядном пределе JVM, равном 2000 МБ), продолжайте, однако этот подход явно не очень хорошо масштабируется, поэтому я бы не стал его предлагать.Если все будет отправлено в одну постоянную очередь, это, вероятно, будет хорошо, однако я бы рекомендовал сначала загрузить прототип под нагрузку, чтобы убедиться.Обработка может быть медленной, но не обязательно медленнее, чем если бы ее выбирал какой-то другой механизм.В любом случае, я бы определенно рекомендовал отправлять меньшие сообщения в отдельные места назначения, где они могут обрабатываться параллельно с большими сообщениями.

Answer 2

Мы запускаем аналогичный сценарий с большим количеством сообщений.Мы сделали это аналогично предложению Andres с использованием разных очередей для большого количества сообщений меньшего размера (которые по-прежнему составляют ~ 3-5 МБ в нашем сценарии) и нескольких больших сообщений размером около 50-150 МБ.

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

Answer 3

причины размер сообщения влияет на пропускную способность (в msgs / sec). чем больше сообщения, тем меньше пропускная способность.