1. Введение
Компоненты, управляемые сообщениями, также известные как «MDB», обрабатывают сообщения в асинхронном контексте. Мы можем изучить основы MDB в этой статье .
В этом учебнике обсуждаются некоторые стратегии и передовые методы реализации параллелизма с использованием компонентов, управляемых сообщениями.
Если вы хотите больше узнать об основах параллелизма с использованием Java, вы можете начать здесь .
Чтобы лучше использовать MDB и параллелизм, необходимо принять во внимание некоторые соображения. Важно иметь в виду, что эти соображения должны определяться бизнес-правилами и потребностями нашего приложения.
2. Настройка пула потоков
Настройка пула потоков, вероятно, является основным объектом внимания. Чтобы эффективно использовать параллелизм, мы должны настроить количество экземпляров MDB, доступных для потребления сообщений . Когда один экземпляр занят обработкой сообщения, другие экземпляры могут принять следующие.
Поток MessageListener отвечает за выполнение метода onMessage MDB. Этот поток является частью пула потоков MessageListener , что означает, что он объединен в пул и повторно используется снова и снова. Этот пул также имеет конфигурацию, которая позволяет нам установить количество потоков, что может повлиять на производительность:
- установка небольшого размера пула приведет к тому, что сообщения будут потребляться медленно («MDB Throttling»)
- установка очень большого размера пула может снизить производительность или вообще не работать.
В Wildfly мы можем установить это значение, обратившись к консоли управления. Возможность JMS не включена в автономном профиле по умолчанию; нам нужно запустить сервер, используя полный профиль .
Обычно при локальной установке доступ к ней осуществляется через http://127.0.0.1:9990/console/index.html. После этого нам нужно зайти в Configuration/Subsystems/Messaging/Server, выбрать наш сервер и нажать «View».
Выберите вкладку «Атрибуты», нажмите «Изменить» и измените значение «Максимальный размер пула потоков». Значение по умолчанию — 30.
3. Настройка максимальных сессий
Еще одно настраиваемое свойство, о котором следует знать, — это Maximum Sessions . Это определяет параллелизм для конкретного порта прослушивателя. Обычно это значение по умолчанию равно 1, но его увеличение может повысить масштабируемость и доступность приложения MDB.
Мы можем настроить его либо с помощью аннотаций, либо с помощью дескрипторов .xml . Через аннотации мы используем @ActivationConfigProperty :
@MessageDriven(activationConfig = {
@ActivationConfigProperty(
propertyName=”maxSession”, propertyValue=”50”
)
})
Если выбран метод конфигурации с дескрипторами .xml , мы можем настроить maxSession следующим образом:
<activation-config>
<activation-config-property>
<activation-config-property-name>maxSession</activation-config-property-name>
<activation-config-property-value>50</activation-config-property-value>
</activation-config-property>
</activation-config>
4. Среда развертывания
Когда у нас есть потребность в высокой доступности, мы должны рассмотреть возможность развертывания MDB в кластере серверов приложений. Таким образом, он может выполняться на любом из серверов в кластере, и многие серверы приложений могут вызывать его одновременно, что также улучшает масштабируемость.
Для этого конкретного случая у нас есть важный выбор:
- сделать все серверы в кластере доступными для получения сообщений , что позволяет использовать всю его вычислительную мощность, или
- обеспечить последовательную обработку сообщений, позволив только одному серверу получать их одновременно
Если мы используем корпоративную шину, рекомендуется развернуть MDB на том же сервере или кластере, что и член шины, чтобы оптимизировать производительность обмена сообщениями.
5. Модель сообщений и типы сообщений
Хотя это не так очевидно, как установка другого значения для пула, модель сообщения и тип сообщения могут повлиять на одно из лучших преимуществ использования параллелизма: производительность.
Например, при выборе XML для типа сообщения размер сообщения может повлиять на время, затрачиваемое на его обработку . Это важное соображение, особенно если приложение обрабатывает большое количество сообщений.
Что касается модели сообщений, если приложению необходимо отправить одно и то же сообщение большому количеству потребителей, модель публикации-подписки может быть правильным выбором . Это уменьшит накладные расходы на обработку сообщений, обеспечив лучшую производительность.
Чтобы потреблять из темы по модели публикации-подписки, мы можем использовать аннотации:
@ActivationConfigProperty(
propertyName = "destinationType",
propertyValue = "javax.jms.Topic")
Опять же, мы также можем настроить эти значения в дескрипторе развертывания .xml :
<activation-config>
<activation-config-property>
<activation-config-property-name>destinationType</activation-config-property-name>
<activation-config-property-value>javax.jms.Topic</activation-config-property-value>
</activation-config-property>
</activation-config>
Если отправка одного и того же сообщения многим потребителям не является обязательным требованием, будет достаточно обычной модели PTP (точка-точка).
Чтобы потреблять из очереди, мы устанавливаем аннотацию как:
@ActivationConfigProperty(
propertyName = "destinationType",
propertyValue = "javax.jms.Queue")
Если мы используем дескриптор развертывания .xml , мы можем установить его:
<activation-config>
<activation-config-property>
<activation-config-property-name>destinationType</activation-config-property-name>
<activation-config-property-value>javax.jms.Queue</activation-config-property-value>
</activation-config-property>
</activation-config>
6. Заключение
Как уже заявляли многие компьютерщики и ИТ-писатели, скорость процессоров больше не растет быстрыми темпами. Чтобы наши программы работали быстрее, нам нужно работать с большим количеством процессоров и ядер, доступных сегодня.
В этой статье обсуждались некоторые рекомендации по максимально эффективному использованию параллелизма с помощью MDB.