Выбор MQ для HighLoad-проекта

Чтобы управлять потоком запросов в микросервисной архитектуре, применяют очереди сообщений MQ (message queues). Но какую MQ лучше выбрать, если речь идет о высоконагруженном проекте?

RabbitMQ

RabbitMQ — один из лидеров по популярности и испытанное временем решение класса Enterprise.

Плюсы: — гарантия доставки (это, по сути, главное, чего можно ожидать от MQ); — гибкая система маршрутизации; — поддержка всевозможных стандартов.

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

Очередь на основе распределенного лога

Можно обратить внимание на платформу Apache Kafka, которая появилась внутри LinkedIn в качестве системы агрегации логов. Kafka способна выжимать из дисковой системы более высокую производительность, чем RabbitMQ, т. к. данные пишутся последовательно (sequential I/O), а не случайно (random I/O). Но, к сожалению, отсутствуют гарантии, что запись на диск всегда будет осуществляться последовательно.

Кроме того: — данные в Kafka делятся по разделам (partition), поэтому для соблюдения порядка доставки каждый получатель читает данные только из одного раздела. Иногда это может быть причиной блокировки очереди, особенно если получатель обрабатывает сообщения медленнее обычного; — для управления кластером Kafka нужен отдельный сервис (zookeeper), что уже усложняет обслуживание, да и нагружает devops.

Таким образом, существуют риски потери производительности, что недопустимо в production.

Высокопроизводительные очереди

Для того чтобы не терять сообщения внутри процесса очереди, вы можете просто убрать процесс очереди, заменив его библиотекой, встроенной в процесс микросервиса. Тут следует вспомнить библиотеку ZeroMQ, показывающую отличную скорость и переваривающую миллионы сообщений/сек. Но в ней отсутствуют встроенные средств мониторинга и управления кластером, поэтому, опять же, нагрузка на devops еще больше возрастает.

NATS

NATS — относительно молодой проект, разработанный Derek Collison. Эта компания имеет больше 20 лет опыта работы над распределенными очередями сообщений.

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

Из плюсов: — простота администрирования кластера NATS; — сообщения в NATS группируются по темам, то есть каждый узел знает, какие именно узлы имеют живых подписчиков и на какие темы; — сообщения доставляются напрямую от отправителя получателю, отсутствуют промежуточные шаги, задержка минимальна; — обеспечивается высокая производительность, которая порой опережает очереди с «гарантированной доставкой»; — NATS написан на языке программирования Go, однако имеет клиентские библиотеки для других популярных языков.

По материалам https://habr.com/ru/post/326880/.

А что посоветуете вы? Пишите в комментариях!