Когда сообщение (например, JMS) является альтернативой для многопоточности?

Question

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

Это привело меня к мысли, почему то же самое не удалось достичь, используя несколько потоков.

Итак, мой вопрос: в каких ситуациях может использоваться асинхронный обмен сообщениями (например, JMS) как альтернатива mutithreading как средство достижения параллелизма? Каковы некоторые преимущества/недостатки использования одного подхода над другим.

Answer 1

Он не может использоваться как альтернатива многопоточности, это способ реализации многопоточности. Существует три основных вида решений:

1. Вы несете ответственность за оба конца очереди;
2. Вы несете ответственность за отправку данных; или
3. Вы несете ответственность за получение данных.

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

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

Answer 2

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

Answer 3

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

Хотя я считаю, что JMS здесь неправильно используется. В потоках и библиотеках java.util.concurrent, таких как jetlang, можно обеспечить лучшую производительность.

Answer 4

В контейнере EJB на самом деле альтернативы нет, так как вам не разрешено создавать собственные потоки в контейнере EJB. JMS делает все это для вас за счет его запуска через процессор очереди. Вы также можете создать Java-коннектор, который имеет более близкие отношения с контейнером (и, следовательно, может иметь потоки), но это намного больше.

Если накладные расходы на использование очереди JMS не оказывают влияния на производительность, то это самое простое решение.

Answer 5

Есть два дополнительных бонусов, которые я не думаю, что было сказано: Сделки и долговечность.

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