Брокеры сообщений — что это, из чего состоят, плюсы и минусы: сравниваем 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 (один ко многим).

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

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

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

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

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

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

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

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

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

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

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

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

заключение

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

• #redis
• #брокеры_сообщений
• #apachekafka
• #rabbitmq