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

Брокер сообщений как показатель зрелости системы

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

Какие проблемы решает брокер сообщения? Представим, что в ваш сервис пришёл новый пользователь и хочет зарегистрироваться. При регистрации он указывает адрес электронной почты, и для его валидации вам нужно послать уведомление с кодом. Чтобы реализовать отправку сообщения, нужно интегрироваться с внешней системой. Но вы не хотите, чтобы пользователь ждал ответа удалённой системы. Вместо этого вы хотите, чтобы его сразу перенаправили на следующую страницу, где будет запрашиваться ввод кода с надписью «Подтвердить электронную почту». Брокер сообщений позволяет выполнять описанные операции асинхронно. 

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

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

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

Зачем использовать брокеры сообщений

Если сломается брокер, в худшем случае вы потеряете часть сообщений, но ядро сервиса всё ещё будет работать, так как берет информацию из базы данных. Сообщения будут накапливаться, и когда сервер вернётся, то быстро прочитает и обработает образовавшийся долг. Но иногда возникает частичная деградация: какая-то информация может оказаться не самой актуальной, хотя пользователи, скорее всего, этого даже не заметят. Пример — новостная лента в соцсетях. Если она не будет обновляться некоторое время, вы все равно сможете посмотреть опубликованные посты. 

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

Второй вариант — настроить брокер сообщений. Так вы сможете обеспечить своему приложению технологический запас для будущего развития. Одним из наиболее популярных брокеров сообщений остаётся RabbitMQ.

Что такое RabbitMQ

RabbitMQ — распределённый и горизонтально масштабируемый брокер сообщений. Упрощённо его устройство можно описать так:

  • паблишер, который отправляет сообщения;

  • очередь, где хранятся сообщения;

  • подписчики, которые выступают получателями сообщений.

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

RabbitMQ отлично подходит для интеграции разных компонентов, создания микросервисов, потоковой передачи данных в режиме реального времени или при передаче работы удалённым работникам. Его используют крупные компании, в числе которых Bloomberg, Reddit, WeWork, NASA и др. 

Почему выбирают RabbitMQ:

  • RabbitMQ поддерживает несколько протоколов: AMQP, MQTT, STOMP и др., что позволяет использовать его в разных сценариях.

  • RabbitMQ хранит сообщение до тех пор, пока принимающее приложение не подключится и не получит его из очереди. Клиент может подтвердить получение сообщения сразу или после того, как полностью обработает его. Как только такое подтверждение получено, сообщение удаляется из очереди. Для сравнения в Kafka очередь сообщений является постоянной — данные хранятся, пока не истечёт указанный период или не будет достигнуто ограничение по размеру. Поэтому важно убедиться, что событие, которое должно произойти один раз, не воспроизводится многократно. 

  • Основное преимущество RabbitMQ — гибкая маршрутизация. Сообщения маршрутизируются через exchange (обменник) перед попаданием в очереди. RabbitMQ предлагает несколько встроенных типов обмена для типичной логики маршрутизации. 

  • RabbitMQ поддерживает приоритезацию в очередях и позволяет настроить диапазон приоритетов. Приоритет каждого сообщения устанавливается при его публикации. 

  • RabbitMQ предлагает простой пользовательский интерфейс управления. Он позволяет контролировать каждый аспект брокера сообщений. .

Сценарии использования RabbitMQ

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

Фоновая обработка данных

Фоновая обработка данных — оптимальный сценарий использования RabbitMQ. Вы можете поместить сообщение в очередь без его немедленной обработки.

Пример: вы хотите загрузить отчёт из приложения. Приложение обрабатывает информацию и генерирует PDF-файл в течение 15-20 минут. Затем отправляет его вам по электронной почте. Очередь сообщений позволяет выполнить все задачи асинхронно.

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

Посредник в микросервисной архитектуре

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

Ещё пара слов о RabbitMQ напоследок

Когда приложение ломается, другие приложения уже не могут обмениваться с ним сообщениями, поэтому работа останавливается. RabbitMQ же кладёт сообщение в очередь, дожидается, пока сломанное приложение починят, и отдаёт ему сообщение из очереди. Да, есть некоторая задержка на время устранения причины поломки, но глобально ничего не падает. 

Также RabbitMQ выполняет распределённые нагрузки. Несколько копий одного приложения могут быть запущены на разных компьютерах. RabbitMQ распределит нагрузку относительно производительности и выберет, кому отправить сообщение. 

RabbitMQ — больше, чем просто брокер сообщений. Он основан на ERLANG и платформе Open Telecom, обеспечивающей высокую производительность при использовании минимальных ресурсов. Его выбирают, когда требуется надёжная доставка сообщений и гибкая маршрутизация. 

Для тех, хочет разобраться в RabbitMQ и получить скидку 10% на обучение

28 сентября у нас стартует курс по Rabbit MQ. На нём инфраструктурный инженер Алексей Барабанов расскажет, как не искать сложных решений там, где достаточно целевого хорошо настроенного инструмента. А ещё поделится кейсами и примерами из своего опыта.

Курс будет полезен тем, кто ещё не знаком с RabbitMQ, и тем, кто давно работает с ним только в базовом исполнении и хочет узнать о новых способах применения, нюансах отказоустойчивости и мониторинга.

Здесь можно ознакомиться с подробной программой и занять место: https://slurm.club/3AFKlyr

А промокод «READER» даст скидку 10% при покупке курса.

Комментарии (14)


  1. veocode
    24.08.2022 15:01
    +8

    Не хватает хотя бы минимального сравнения с другими решениями. Зачем, например, тащить RabbitMQ для фоновой отправки почты, если можно взять что-то попроще для pub/sub, типа Redis


    1. geniyoctober
      24.08.2022 15:05

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


    1. KiLEX
      26.08.2022 07:55

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

      Я бы для отправки почты также взял реббит - потому что он умеет хранить и может перенести рестарт и смерть всех сервисов. Редис если честно не впечатлил


  1. Yak52
    24.08.2022 15:20
    +5

    Вот тут не совсем понятно:

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

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


    1. MechanicusJr
      24.08.2022 21:05
      +1

      Если сломается брокер, в худшем случае вы потеряете часть сообщений,

      Вот будет очень приятно потерять секунд 15 биржевых или карточных транзакций


      1. KiLEX
        26.08.2022 07:56

        Если у вас транзакции - то извольте делать отказоуйстойчивый кластер. Тут карты в руки каждому


    1. KiLEX
      26.08.2022 07:58

      Речь видимо шла о том что сам сервис продолжит работу в формате - интерфейс открывается, данные на момент до падения брокера - отображаются.

      Но да, если речь о отказоустойчивой инфраструктуре надо мало того что делать кластер, но еще и резервировать потоки в другие ДЦ и реализовывать внутренние очереди сервисов-паблишеров. Например можно рядом с паблишером сайдкаром поднимать реббит с шовелом в прод кластер.


    1. a-postx
      26.08.2022 15:39

      Сервисы не становятся слепы или глухи, в них просто перестают происходить события.

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

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


  1. felixd7u
    24.08.2022 19:57
    -1

    Крайне приятно встретить в сети конспект по своему видео на Youtube трехлетней давности.


    1. geniyoctober
      25.08.2022 03:30

      Тогда все вопросы к провайдерам managed-решений RabbitMQ, мы при написании статьи отталкивались от их технических материалов.


  1. MechanicusJr
    24.08.2022 20:58
    +1

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

    Разве RabbitMQ поддерживает гарантированную доставку? В нем вроде с журналом транзакций никак.

    Когда приложение ломается, другие приложения уже не могут обмениваться с ним сообщениями, поэтому работа останавливается. RabbitMQ же кладёт сообщение в очередь

    Так, вы же пишете про гарантированную доставку? А что будет при падении самого RabbitMQ - где будут сохранены очереди?

    А то дока что-то пишет про

    No guarantees are provided for messages that have not been confirmed using the publisher confirm mechanism. Such messages could be lost "mid-way", in an operating system buffer or otherwise fail to reach the queue leader.

    For example, a queue with three replicas can tolerate one node failure without losing availability. A queue with five replicas can tolerate two, and so on.

    If a quorum of nodes cannot be recovered (say if 2 out of 3 RabbitMQ nodes are permanently lost) the queue is permanently unavailable and will need to be force deleted and recreated.


    1. tm1218
      25.08.2022 00:22
      +1

      Гарантированная доставка в случае отработки механизма подтверждения. Как можно гарантировать доставку в случае, к примеру, потери сети? Об этом и речь в документации.


      1. MechanicusJr
        25.08.2022 20:20

        Как можно гарантировать доставку в случае, к примеру, потери сети?

        Точно так же, как лет 40 (или больше) работает в банковских транзакциях. Когда сети не было вообще.


  1. tm1218
    25.08.2022 00:25

    WhatsApp вроде тоже на кролике изначально базировался?