TOC

Параллельные стратегии с использованием MDB

Параллельные стратегии с использованием МБР

1. Вступление

Компоненты, управляемые сообщениями, также известные как «MDB», обрабатывают обработку сообщений в асинхронном контексте. Мы можем изучить основы MDB вthis article.

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

Если вы хотите больше узнать об основах параллелизма с использованием Java, вы можете начатьhere.

Чтобы лучше использовать MDB и параллелизм, необходимо сделать несколько замечаний. It’s important to keep in mind that those considerations should be driven by the business rules and the needs of our application.с

2. Настройка пула потоков

Настройка пула потоков, вероятно, является основным моментом внимания. Чтобы эффективно использовать параллелизм, мы должныtune the number of MDB instances available to consume messages. Когда один экземпляр занят обработкой сообщения, другие могут получить следующие.

ПотокMessageListener отвечает за выполнение методаonMessage MDB. Этот поток является частью пула потоковMessageListener, что означает, что он объединен в пул и используется снова и снова. This pool also has a configuration that allows us to set the number of threads, which may impact the performance:

  • установка небольшого размера пула приведет к медленному использованию сообщений («регулирование MDB»)

  • установка очень большого размера пула может снизить производительность или вообще не работать.

НаWildfly мы можем установить это значение, зайдя в консоль управления. Возможность JMS не включена в автономном профиле по умолчанию; нам нужно запустить сервер, используяfull profile.

Обычно при локальной установке мы получаем к нему доступ через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 следующим образом: 


    
        maxSession
        50

4. Среда развертывания

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

Для этого конкретного случая у нас есть важный выбор:

  • makeall servers in the cluster eligible to receive messages, что позволяет использовать всю свою вычислительную мощность, или

  • обеспечить обработку сообщения вsequential manner by allowing just one server to receivethem at a time

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

5. Модель сообщения и типы сообщений

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

При выборе XML для типа сообщения, например,the size of the message can affect the time spent to process it. Это важное соображение, особенно если приложение обрабатывает большое количество сообщений.

Что касается модели сообщения,if the application needs to send the same message to a lot of consumers, a publish-subscribe model might be the right choice. Это уменьшит накладные расходы на обработку сообщений, обеспечивая лучшую производительность.

Чтобы использоватьTopic в модели публикации-подписки, мы можем использовать аннотации: 

@ActivationConfigProperty(
  propertyName = "destinationType",
  propertyValue = "javax.jms.Topic")

Опять же, мы также можем настроить эти значения в дескрипторе развертывания.xml: 


    
        destinationType
        javax.jms.Topic

Если отправка одного и того же сообщения множеству потребителей не является обязательным требованием, будет достаточно обычной модели PTP (точка-точка).

Чтобы использовать из очереди, мы устанавливаем аннотацию как: 

@ActivationConfigProperty(
  propertyName = "destinationType",
  propertyValue = "javax.jms.Queue")

Если мы используем дескриптор развертывания.xml, мы можем установить его: 


    
        destinationType
        javax.jms.Queue

6. Заключение

Как уже отмечали многие компьютерные ученые и писатели в области ИТ, скорость процессоров у нас больше не растет быстрыми темпами. Чтобы наши программы работали быстрее, нам нужно работать с большим количеством процессоров и ядер, доступных сегодня.

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

Related