Зачем нужны брокеры сообщений в программировании

Брокеры сообщений, или Как происходит взаимодействие в рамках распределённой инфраструктуры

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

Что будет, если ввести этот элемент в вашу архитектуру? И почему это особенно актуально сейчас, когда так широко распространился микросервисный подход к проектированию систем? Обсудим это сегодня. Все подробности — под катом.

Брокер сообщений представляет собой тип построения архитектуры, при котором элементы системы «общаются» друг с другом с помощью посредника. Благодаря его работе происходит снятие нагрузки с веб-сервисов, так как им не приходится заниматься пересылкой сообщений: всю сопутствующую этому процессу работу он берёт на себя.

Можно сказать, что в работе любого брокера сообщений используются две основные сущности: producer (издатель сообщений) и consumer (потребитель/подписчик).

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

Здесь возможны несколько вариантов:

Сообщение отправляется напрямую от отправителя к получателю.

В этом случае каждое сообщение используется только однократно;

Схема публикации/подписки.

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

Для чего нужны брокеры сообщений?

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

Недостатки брокеров сообщений:

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

Когда брокеры сообщений могут быть полезны:

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

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

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

Какие есть брокеры сообщений?

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

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

Малое время задержки для прохода сообщения по сети, а также возможность двунаправленной связи в реальном времени (так как MQTT является надстройкой над дуплексным протоколом websockets) позволяют реализовывать достаточно интересные применения. Среди них может быть даже управление робототехническими устройствами в реальном времени. При таком управлении задержка не превышает десятков миллисекунд, что вполне допустимо для низкоскоростных устройств. Например, для управления роботами, движущимися в промышленных цехах и использующимися для перевозки деталей от станков или сырья к производственным станкам.

Также информационные системы на базе протокола MQTT используются в автомобильной сфере и в ряде других промышленных областей (HiveMQ).

Apache Kafka и RabbitMQ: что выбрать?

В корпоративных инфраструктурных системах популярностью пользуются Apache Kafka и RabbitMQ. В связи с чем часто возникает вопрос, какую из них выбрать в конкретном случае?

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

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

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

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

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

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

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

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

Platform V Corax

В экосистеме Сбера для приложений с микросервисной архитектурой есть также свой брокер сообщений.

Platform V Corax – программный продукт, предназначенный для автоматизации развёртывания, масштабирования контейнеризированных приложений и управления ими с использованием платформы Kubernetes путём предоставления REST API. Выполняет функции развёртывания, администрирования и учёта ресурсов инсталляций Kafka.

Platform V Corax – это платформа для работы с потоками данных, обладающая высокой производительностью и отказоустойчивостью. Разработана на базе открытого программного обеспечения Apache Kafka.

Она сохраняет рыночные преимущества свободно распространяемой версии Apache Kafka и имеет контролируемый и сокращённый релизный цикл по сравнению с open source-версией. Функциональность продукта соответствует запросам Enterprise-клиентов.

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

Пример использования Platform V Corax – непрерывная передача информации с конечных устройств в платформу. Данные не только передаются, но и обрабатываются множеством клиентов, которые называются подписчиками (consumers). В роли подписчиков могут выступать приложения и программные сервисы.

Преимущества:

Горизонтальное масштабирование.
Высокая скорость передачи сообщений.
Поддержка транзакций.
Контроль доступа через SASL.
TLS-шифрование.
Аудит изменения конфигурации кластера.

Platform V Corax поставляется вместе с UI-интерфейсом, реализующим все базовые элементы управления сервисом.

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

Выбирая нужный брокер, следует исходить из глубокого понимания вашей системы и её потребностей. Например, если нужно построение сложных сценариев маршрутизации, можно выбрать известный брокер RabbitMQ. Если же вы проектируете высоконагруженные системы, то советуем остановиться на Apache Kafka – он отлично справляется с этой задачей. А если у вас enterprise-разработка – отличным решением будет Platform V Corax.

Блог компании Сбер
IT-инфраструктура
Сетевые технологии
Микросервисы

Брокеры сообщений — что это, из чего состоят, плюсы и минусы: сравниваем Apache Kafka, Redis и RabbitMQ

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

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

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

ИЗ ЧЕГО СОСТОИТ БРОКЕР СООБЩЕНИЙ

В работе любого брокера сообщений используются две основные сущности:

Producer / Publisher — занимается отправкой сообщения в брокер;
Consumer / Subscriber — получает и обрабатывает сообщения из брокера;

Сообщение отправляется напрямую от отправителя к получателю.

Также есть Topic / Тема — логическая единица, которая объединяет все сообщения по некоторому критерию.

Есть два основных алгоритма передачи сообщений в очередь:

Есть Producer , который направляет сообщения в брокер, и есть Consumer, который их получает.
Есть Publisher , который закидывает сообщения в очередь, и есть n-ое количество Subscriber ‘ов, которые их обрабатывают в дальнейшем.

КОГДА НУЖНО ИСПОЛЬЗОВАТЬ БРОКЕРЫ

Существует много кейсов, в которых применяются брокеры. Разберем основные:

Отложенное выполнение действий. Потребность использовать брокеры возникает, когда нужно выполнить тяжелые операции, но не обязательно их выполнять в момент запроса от пользователя. Например, чтобы сформировать отчет, мы не должны заставлять пользователя ждать, пока пройдет время, и появится результат. Вместо этого мы отправляем задачу в очередь и даем клиенту ответ, что процесс запущен и ответ формируется.
Реализация асинхронного обмена между сервисами с обеспечением буферизации сообщений . В данном случае брокер будет выступать неким буфером для накопления сообщений. И мы можем регулировать нагрузку и в некоторых кейсах ускорять обработку данных, по сравнению с тем, что если бы мы делали это однопоточно.
Осуществление сложной бизнес-логики, в которой задействовано несколько компонентов информационной системы. В основном это касается микросервисов. Часто нужно выполнять изменения, которые должны происходить в нужной последовательности. Брокер поможет этому процессу. Получив сообщения в первом сервисе, выполняются необходимые изменения, и закидывается следующая задача для второго сервиса.
Сглаживание пиковых нагрузок . Отправить какую-то задачу в брокер быстрее, чем ее выполнить. Поэтому мы можем накапливать определенные действия, а их выполнение делать уже позже.
Отправка уведомлений (чаще перекликается с пунктом выше). Например, если идет массовая регистрация на мероприятие, мы хотим всем отправить подтверждение регистрации. Для того чтобы не перегружать основную часть системы отправкой уведомлений , мы просто складываем эти задачи в брокер, и потом в фоновом режиме работаем с ними.
Когда требуется агрегировать и выполнять задачи по расписанию либо собирать данные телеметрии, логи и статистики . Запись в файл или передача в какую-то другую систему для агрегации этой информации — достаточно трудоемкий процесс. За счет использования очередей мы можем снизить нагрузку на наш основной сервис. Потому что это не первичная задача для бизнес-логики, мы можем выполнять ее фоново. И это никак не повлияет на производительность системы для пользователя.

ПЛЮСЫ И МИНУСЫ ИСПОЛЬЗОВАНИЯ БРОКЕРОВ

Как и у любой другой технологии, у брокеров сообщений есть свои плюсы и минусы:

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

какой БРОКЕР в каких случаях использовать

Выбор брокера сообщений зависит от конкретных требований и контекста использования.

Apache Kafka	RabbitMQ	Redis
когда нужно обработать большой объем данных, которые очень быстро генерируются	нет большого потока данных	необходима обработка больших объемов данных
при реализации транзакционных или конвейерных систем	важна гибкость маршрутизации сообщений внутри системы	не требуется персистентность
при построении событийно-ориентированной архитектуры	важен факт доставки сообщений	необходима высокая скорость доставки сообщений
при использовании буфера для логов и метрик

заключение

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

Брокер сообщений Redis — Основы Redis

Представьте, что вы пишете back-end интернет-магазина. Когда клиент оставляет заказ, сервер сохраняет данные в БД, отправляет чек клиенту на электронную почту и передает информацию в отдел обработки заказов. Самый простой способ реализовать этот алгоритм — выполнять все последовательно синхронно. Однако при разработке веб-приложений всегда стоит учитывать, что что-то может пойти не так. Провайдер электронных писем может иметь технические проблемы, из-за чего отправка письма задержится на несколько секунд или письмо не отправится с первого раза.

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

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

Message Brokers

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

Back-end сервис кладет сообщения в брокера
С другой стороны сервис-обработчик (worker) читает сообщения из брокера и как-то их обрабатывает
Сообщения внутри брокера буферизируются и формируется очередь. Если в один момент времени нужно записать 10 тыс. сообщений, они запишутся без задержки, а потом обработаются за какой-то промежуток времени

Redis Message Broker

Многие проекты используют Redis как брокер сообщений из-за простоты интеграции. Популярные фреймворки абстрагируют от разработчика внутреннюю реализацию очередей в Redis. Однако в некоторых языках (например, Golang) можно интегрироваться самому.

Простая реализация

Рассмотрим простую реализацию очереди в Redis на примере оформления заказа в интернет магазине. При оформлении заказ сохраняется в БД синхронно, после этого кладется сообщение в 2 очереди для отправки электронного письма и передачи заказа в сервис обработки. Каждая очередь является списком (Lists). Чтобы положить сообщение в конец очереди, используется команда rpush . С другой стороны сервисы-обработчики слушают очередь командой blpop .

Допустим, пользователь с ID 33 оставил заказ. В этом случае будут выполнены следующие команды:

'' (integer) 1 127.0.0.1:6379> rpush queue:order:processing '' (integer) 1

Проверим, что сообщения успешно сохранились в списках:

-1 1) "\"user_id\":33,\"order_id\":12345>" 127.0.0.1:6379> lrange queue:order:processing 0 -1 1) "\"user_id\":33,\"order_id\":12345>"

Сервисы обработчики слушают очередь с помощью команды blpop key [key . ] timeout :

) "queue:order:mail_notification" 2) "\"user_id\":33,\"order_id\":12345>" 127.0.0.1:6379> blpop queue:order:processing 10 1) "queue:order:processing" 2) "\"user_id\":33,\"order_id\":12345>"

Команда blpop — это блокирующее чтение списка. Если список пуст, то выполнение программы блокируется до наступления таймаута, указанного в последнем аргументе в секундах. Если в списке есть элементы, то команда удалит самый левый элемент списка и вернет его. Удаление и чтение происходит атомарно, то есть при нескольких одновременных запросах не может быть ситуации, когда один элемент прочитался более 1 раза.

В такой схеме есть значимый изъян. Если сервис обработчик достанет сообщение из очереди и упадет, не до конца его обработав, то сообщение потеряется навсегда. Надеяться, что система всегда будет работать как задумано (happy path), не стоит.

Надежные очереди в Redis

Успешно обработать ситуации, когда сервис не до конца обрабатывает сообщение, можно с помощью команды blmove source destination LEFT|RIGHT LEFT|RIGHT timeout . Эта команда также блокирует выполнение при пустом списке. Если в списке есть элементы, то самый левый элемент списка возвращается, удаляется из списка source и сохраняется в запасном списке destination.

'' (integer) 1 127.0.0.1:6379> blmove queue:order:mail_notification queue:order:mail_notification:fallback LEFT RIGHT 10 "\"user_id\":33,\"order_id\":12345>"

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

Ошибки инфраструктуры

Отметим один важный момент. Если по какой-то причине упадет сам Redis сервер, то данные за последние несколько секунд могут быть потеряны. Этого можно избежать специальной настройкой персистентности данных, которая понизит производительность. Всегда присутствует компромисс между пропускной способностью и надежностью хранения. Детальное изучение настроек Redis-сервера выходит за рамки данного курса, но при необходимости нужную информацию можно найти в интернете.

Резюме

все, что может быть выполнено асинхронно, нужно выносить в обработку через очереди
Redis — простой брокер очередей, который покрывает нужды большинства небольших проектов
очереди в Redis реализуются с помощью встроенной структуры данных Lists

Открыть доступ

Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно

130 курсов, 2000+ часов теории
1000 практических заданий в браузере
360 000 студентов

Наши выпускники работают в компаниях:

Брокеры сообщений: RabbitMQ и Kafka

Запись открытого урока онлайн-курса «Microservice Architecture «

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

На этом открытом занятии мы ознакомились с основными принципами работы этих брокеров, а также посмотрели использование этих брокеров в live demo.

Спикер: Евгений Непомнящи, C++ и Java разработчик.