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

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

 

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

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

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

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

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

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

 

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


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

 

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

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

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

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

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

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

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

+ -
Отказоустойчивость и масштабируемость. Способствует созданию отказоустойчивых и масштабируемых систем благодаря асинхронной обработке данных и возможности использовать кластеры брокеров. Усложнение системы. Использование брокеров повлечет за собой увеличение сложности системы за счет добавления нового элемента в нее. Усложняется отладка, обслуживание и администрирование.
Разделение слоев. Допускает разделение слоев приложения, уменьшая связность между ними, что предоставляет возможность сделать приложение более модульным, гибким и удобным в разработке. Также будет полезен при организации микросервисной системы. Сложность в освоении. Изучение данного ПО может занять длительный период времени из-за сложности архитектуры.

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

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

ПОПУЛЯРНЫЕ БРОКЕРЫ СООБЩЕНИЙ

На самом деле, на рынке сейчас существует огромное количество брокеров сообщений. Например, Apache Kafka, RabbitMQ, Redis, Apache ActiveMQ, Amazon SQS, Apollo, Google Pub/Sub и другие. Этот список можно продолжать долго, но мы остановимся на первых трех. Так как они чаще всего используются в современной разработке. 

 

Мы сравнили брокеры по ряду критериев. Для сравнения выделим три основных критерия, которые будут влиять на выбор:

  1. Scale (масштаб брокера)  —  количество сообщений, отправляемых в системе, в секунду.
  2. Data Persistency (постоянное хранение данных, персистентность)  —  возможность восстановления сообщений.
  3. Клиентские возможности  —  способность управлять клиентами в режиме one-to-one (один к одному) и/или one-to-many (один ко многим).
 Брокер Scale Data Persistency Клиентские возможности

Apache Kafka

Очень быстрый, позволяет обрабатывать более 1 млн сообщений в секунду Да One-to-many
RabbitMQ Около 50 тысяч сообщений в секунду (зависит от конфигурации) Поддерживает  постоянные и временные сообщения One-to-one и one-to-many
Redis До 1 млн сообщений в секунду Частичная реализация One-to-one и one-to-many

Особенности Apache Kafka

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

  • Подписчики должны сами «забирать» сообщения;
  • Постоянное хранение данных. Все сообщения хранятся ограниченное количество времени, которое конфигурируется на уровне брокера. 
  • Позволяет перечитывать сообщения.
  • Гарантирует порядок сообщений в разрезе топика. В каком порядке publisher прислал сообщения, в таком порядке subscriber их и получит.

Особенности Rabbit MQ

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

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

Есть сложности при горизонтальном масштабировании в кластере.

Особенности Redis

  • Резервное копирование на определенный момент времени;

  • Имеет ограниченный функционал по сравнению с другими брокерами.

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

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

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

заключение

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