В модели обмена сообщениями точка-точка отправитель отправит сообщение, а после того, как брокер сообщений получит сообщение, он будет держать сообщение в очереди. Как только получатель снова подключится к сети, брокер сообщений выведет сообщение из очереди и отправит его получателю. Это происходит в порядке очереди (FIFO).
Сообщения будут получены в том порядке, в котором они были отправлены. Пример, который я объяснил в начале этой статьи о брокере сообщений, можно рассматривать как реальный пример.
Основные характеристики этой модели:
- У каждого сообщения есть только один потребитель.
- Отправителю и получателю не требуется одновременное соединение для связи.
- Получатель подтвердит получение сообщения.
- Очередь долговечна (сообщения сохраняются, даже если обе стороны не подключены).
Системы, которые могут использовать этот тип брокера сообщений, вносят деньги на ваш счет, и система бронирования также использует этот тип модели.
Публикация / подписка на модель обмена сообщениями
Вышеупомянутая двухточечная модель хороша для связи с одним узлом. Но если отправитель должен взаимодействовать с несколькими узлами, точка-точка использовать нельзя. Вот где модель публикации / подписки наиболее ярко проявляется.
Для облегчения понимания я сначала приведу пример из реальной жизни. Представьте, что вы участвуете в конференц-связи, вы говорите, и все участники этого вызова будут слышать ваше сообщение. Если один человек уйдет из разговора, а затем присоединится через некоторое время, этот человек пропустил бы слова, которые вы произнесли в то время.
Как видно из приведенной выше диаграммы, в этой модели тема будет получать сообщения от издателя (отправителя), а затем будет транслировать их подписчикам (получателям), которые в настоящее время подписаны на тему (брокер сообщений). Отправителю не нужно знать количество получателей. В этой модели, если пользователь присоединяется поздно, он получит предыдущие сообщения.
Ключевые характеристики этой модели:
- У каждого сообщения может быть 0, 1 или более подписчиков.
- Издатели и подписчики зависят от времени. Оба должны быть подписчиками, должны быть подключены одновременно для получения сообщений.
- По умолчанию тема является недолговечной, что означает, что если подписчик не подключен к теме во время трансляции, он не получит сообщение позже.
Примечание. Согласно JMS (Спецификация обмена сообщениями Java) раздел API может быть недолговечным, чтобы подписчики, подключившиеся с опозданием, также могли получать пропущенный контент.
Брокеры сообщений в настоящее время следуют JMS, которая является спецификацией обмена сообщениями Java. Примером брокера сообщений, использующего JMS, является Kafka.
Итак, в заключение, я надеюсь, вы все поняли, что такое брокер сообщений и зачем нам нужны брокеры сообщений, а также когда REST действительно становится асинхронным.
