Сравниваем эффективность Redis, Kafka и RabbitMQ

Чтобы обеспечить асинхронную связь между микросервисами (microservices), нужен брокер сообщений (message broker). Брокер обеспечивает надежную и стабильную передачу данных, управление и мониторинг, а также предотвращает потерю сообщений. На сегодняшний день существует несколько брокеров, которые различаются по возможностям и объемам передаваемых данных. Сравним три наиболее популярных из них — RabbitMQ, Kafka и Redis.

Синхронная и асинхронная связь между микросервисами

Чтобы обеспечить взаимодействие между микросервисами, используют два распространенных способа: синхронный и асинхронный. В первом случае вызывающая сторона ожидает ответа перед отправкой сообщения, работая как протокол REST (Representational state transfer) поверх HTTP. Во втором — сообщения отправляются, не ожидая ответа. Такой вариант подходит для распределенных систем и обычно нуждается в брокере для управления сообщениями.

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

Преимущества асинхронной связи

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

Кроме того, при использовании брокеров сообщений вместо протокола REST, участвующим в обмене данными сервисам не нужно знать друг о друге. Новый сервис можно добавить к уже давно работающему, т. е. они более “развязаны”.

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

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

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

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

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

Режим one-to-one

Режим one-to-many

Сравнение брокеров сообщений

RabbitMQ (AMQP)

- Scale. Зависит от конфигурации и ресурсов, приблизительно около 50 тысяч сообщений в секунду.
- Persistency. Поддерживаются как постоянные, так и временные сообщения.
- One-to-one и one-to-many. Поддерживаются оба режима.

RabbitMQ — один из первых брокеров общих сообщений, выпущенный в 2007 году. Это приложение с открытым исходным кодом реализует расширенные протоколы очереди сообщений (AMQP). Сообщения доставляются и методом point-to-point, и методом pub-sub. Поддерживается сложная логика маршрутизации.

Есть несколько управляемых сервисов, которые позволяют использовать RabbitMQ как SaaS, но он не входит в стек крупных облачных провайдеров. RabbitMQ поддерживается всеми основными языками, включая Python, Java, .NET, PHP, Ruby, JavaScript, Go, Swift и другие.

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

Kafka

- Scale. До 1 млн сообщений в секунду.
- Persistency. Доступно.
- One-to-one и one-to-many. Поддерживается только one-to-many.

Kafka был разработан Linkedin в 2011 году для обработки данных при высокой пропускной способности и с малой задержкой. Распределенная потоковая платформа Kafka имитирует сервис публикации и подписки (publish-subscribe service). Она обеспечивает постоянное хранение данных и потоков записей, что позволяет обмениваться качественными сообщениями.

Kafka доступна как SaaS на Azure, AWS и Confluent, которые являются создателями и основными участниками этого проекта. Kafka поддерживается всеми основными языками, включая Python, Java, C/C++, Clojure, .NET, PHP, Ruby, JavaScript, Go, Swift и другие.

Redis

- Scale. До 1 млн сообщений в секунду.
- Persistency. Встроенная память для хранения данных отсутствует.
- One-to-one и one-to-many. Поддерживаются оба режима.

Redis немного отличается от других брокеров сообщений. Он предоставляет высокопроизводительное хранилище данных в памяти, которое можно использовать для хранения ключей, либо как брокер сообщений. Еще одна особенность заключается в том, что Redis не обладает персистентностью (механизм постоянного хранения данных), а наоборот сбрасывает данные на диск/в базу данных. Этот брокер идеально подходит для обработки данных в режиме реального времени.

Изначально Redis не поддерживал режимы one-to-one и one-to-many. Однако в версии Redis 5.0 после расширения возможностей pub-sub появился one-to-many.

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

Сравним еще раз возможности RabbitMQ, Kafka и Redis. Все три брокера успешно выполняют свои задачи, но действуют при этом совершенно по-разному. Вот рекомендации по выбору в соответствии с особенностями использования.

Сообщения с коротким жизненным циклом — Redis

Резидентная (in-memory) база данных Redis почти идеально подходит для обмена кратковременными сообщениями, когда не требуется персистентность. Благодаря чрезвычайно быстрому обслуживанию и резидентной памяти Redis идеально подходит для обмена сообщениями с незначительной задержкой, когда персистентность не так важна и можно допустить некоторые потери. С версии 5.0 появилась поддержка режима one-to-many, что было необходимо из-за ограниченных ранее возможностей pub-sub.

Большие объемы данных — Kafka

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

Сложная маршрутизация — RabbitMQ

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

И финальный этап

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

Например, если в системе есть Celery для Task Queue поверх RabbitMQ, удобнее работать с RabbitMQ или Redis, а не с Kafka, который не поддерживается и потребует написания дополнительного кода.

https://nuancesprog.ru/p/15110/