HackMDСравнение очередей
Основные показатели, по которым можно оценивать очереди, это:
- Кластеризуемость (суб-линейная масштабируемость)
- Надёжность (durability)
- Гарантия доставки (<1, >1), подтверждение доставки
- Доступность или консистентность (как и БД)
- Функциональность очередей (маршрутизация, приоритеты, отложенные задачи, балансировка, pub-sub)
- Поддержка протоколов, удобство подключения, наличие SDK
- Обслуживание и мониторинг
- Потребление ресурсов
На сегодняшний день рынок очередей можно вкратце разделить на следующие группы:
- AMQP based. Подавляющее большинств решений написаны на Java и находятся под "зонтиком" Apache Foundation.
Обладают обширной функциональностью одередей, pub/sub'а и диспетчеризации, но крайне плохо масштабируются горизонтально
Основные игроки:
- ActiveMQ
- Java. Нет своего стораджа. Нет HA. (Обеспечивается стораджем).
- посредственная производительность (~ 5krps)
- посредственное поведение при переполнении (деградация)
- Высокое потребление ресурсов CPU/RAM
- Система для средней нагрузки, с RDBMS хранилищами может использоваться для высокой транзакционной целостности
- RabbitMQ
- Erlang. В Single режиме работает хорошо. Кластерных режимов много, но работают плохо. Может терять сообщения, может "не взлетать"
- хорошая производительность single (~ 20krps)
- плохое поведение при переполнении и развале кластера (отказ в обслуживании, ресинк переполненного кластера может занимать часы)
- Высокое потребление ресурсов CPU/RAM
- Система для средней нагрузки, "поставил и работает", без требований к HA 24/7
- Kafka. Изначально создаваемая, как распределённый лог транзакций, обросла обширной функциональностью очередей. С одной стороны базовая инсталляция довольно не самая простая (требует дополнительно Zookeeper), но обладает отличными эксплуатационными характеристиками за счёт удачной архитектуры. Обладает дополнительной возможностью в сравнении с классическими очередями в виде множественных потребителей на один поток данных (позволяет организовывать reactive flow)
- Java.
- Почти линейно масштабируется.
- Встроенный HA за счёт использования Zookeeper, высокодоступная
- Высокая гарантия доставки с ≈1
- высокая производительность (100krps+, ограничена скоростью записи на диск)
- Capacity ограничена только дисковым хранилищем
- хорошее поведение при переполнении и развале кластера (понятное, легко управляемое и устраняемое). ресинк кластера выполняется за секунды
- Умеренное потребление ресурсов CPU/RAM
- Система для высоконагруженного надёжного процессинга потоков данных с возможностью использовать множественных потребителей
- Распределённые, децентрализованные системы. Обладают крайне высоким уровнем доступности и почти линейным масштабированием при достаточных гарантиях на надёжность доставки. Хороший пример:
- NSQ
- Golang.
- Почти линейно масштабируется.
- Высокодоступная.
- Высочайшая производительность (800krps+ / 3 node cluster)
- Умеренная гарантия доставки
- Сложнореализуемая durability
- Система для высоконагруженного онлайна 24/7, когда сообщение из потока можно потерять
-
Tarantool (Queue). Не является брокером очередей в классическом понимании. Это библиотека на lua, написанная поверх базы данных. Может использоваться как noHA в режиме single-instance. Может использоваться как элемент кластера. Выбор топологии кластера и сборка первоначально осуществляется вручную. Возможны многие режимы работы в зависимости от задачи (можно собрать High HA, Scalable, Durable, Non-durable, >1, <1). При использовании дополнительных модулей (или их самостоятельной реализации) можно реализовать произвольную логику по работе с задачами. Основные недостатки: отсутствие готовых механизмов переключения мастера (может быть решено при помощи etcd/zookeeper), отсутствие синхронной репликации (не позволяет реализовать одновременно автофейловер и ≈1). Имеются альтернативные реализации
- C/Lua.
- Почти линейно масштабируется.
- Хорошая производительность single node (20krps)
- Конфигурируемые топологией durability и HA
- Низкое потребление CPU, высокое потребление ресурсов RAM
- хорошее поведение при переполнении (переход в RO)
- хорошее поведение при развале кластера (легко управляемое и устраняемое). ресинк кластера выполняется за секунды
- Система для построения производительного решения с заданными характеристиками по надёжности и доступности и произвольной дополнительной логикой
-
Brokerless. Единственный более менее популярный пример — ZeroMQ. Представляет из себя инструмент в виде набора библиотек и подходов для построения собственного data-flow. Её иногда называют сокетами на стероидах. Разработка с использованием ZMQ требует высоких компетенций. Не может выступать в роли очереди "взял, поставил — работает".
-
Cloud based. Пример: Amazon SQS. Для потребителя является наиболее удобным вариантом, т.к. является масштабируемым и надёжным, cloud-native вариантом с гарантией доставки ≈1 (>1).
