# Сравнение очередей

Основные показатели, по которым можно оценивать очереди, это:
1. Кластеризуемость (суб-линейная масштабируемость)
2. Надёжность (durability)
3. Гарантия доставки (<1, >1), подтверждение доставки
4. Доступность или консистентность (как и БД)
5. Функциональность очередей (маршрутизация, приоритеты, отложенные задачи, балансировка, pub-sub)
6. Поддержка протоколов, удобство подключения, наличие SDK
7. Обслуживание и мониторинг
8. Потребление ресурсов

На сегодняшний день рынок очередей можно вкратце разделить на следующие группы:
1. AMQP based. Подавляющее большинств решений написаны на Java и находятся под "зонтиком" Apache Foundation.
Обладают обширной функциональностью одередей, pub/sub'а и диспетчеризации, но крайне плохо масштабируются горизонтально
Основные игроки:
* [ActiveMQ](https://activemq.apache.org/)
+ Java. Нет своего стораджа. Нет HA. (Обеспечивается стораджем).
+ посредственная производительность (~ 5krps)
+ посредственное поведение при переполнении (деградация)
+ Высокое потребление ресурсов CPU/RAM
+ Система для средней нагрузки, с RDBMS хранилищами может использоваться для высокой транзакционной целостности
* [RabbitMQ](https://www.rabbitmq.com/)
+ Erlang. В Single режиме работает хорошо. Кластерных режимов много, но работают плохо. Может терять сообщения, может "не взлетать"
+ хорошая производительность single (~ 20krps)
+ плохое поведение при переполнении и развале кластера (отказ в обслуживании, ресинк переполненного кластера может занимать часы)
+ Высокое потребление ресурсов CPU/RAM
+ Система для средней нагрузки, "поставил и работает", без требований к HA 24/7

2. [Kafka](https://kafka.apache.org). Изначально создаваемая, как распределённый лог транзакций, обросла обширной функциональностью очередей. С одной стороны базовая инсталляция довольно не самая простая (требует дополнительно Zookeeper), но обладает отличными эксплуатационными характеристиками за счёт удачной архитектуры. Обладает дополнительной возможностью в сравнении с классическими очередями в виде множественных потребителей на один поток данных (позволяет организовывать reactive flow)
+ Java.
+ Почти линейно масштабируется.
+ Встроенный HA за счёт использования Zookeeper, высокодоступная
+ Высокая гарантия доставки с ≈1
+ высокая производительность (100krps+, ограничена скоростью записи на диск)
+ Capacity ограничена только дисковым хранилищем
+ хорошее поведение при переполнении и развале кластера (понятное, легко управляемое и устраняемое). ресинк кластера выполняется за секунды
+ Умеренное потребление ресурсов CPU/RAM
+ Система для высоконагруженного надёжного процессинга потоков данных с возможностью использовать множественных потребителей
3. Распределённые, децентрализованные системы. Обладают крайне высоким уровнем доступности и почти линейным масштабированием при достаточных гарантиях на надёжность доставки. Хороший пример:
* [NSQ](https://nsq.io)
+ Golang.
+ Почти линейно масштабируется.
+ Высокодоступная.
+ Высочайшая производительность (800krps+ / 3 node cluster)
+ Умеренная гарантия доставки
+ Сложнореализуемая durability
+ Система для высоконагруженного онлайна 24/7, когда сообщение из потока можно потерять

4. [Tarantool (Queue)](https://github.com/tarantool/queue). Не является брокером очередей в классическом понимании. Это библиотека на lua, написанная поверх базы данных. Может использоваться как noHA в режиме single-instance. Может использоваться как элемент кластера. Выбор топологии кластера и сборка первоначально осуществляется вручную. Возможны многие режимы работы в зависимости от задачи (можно собрать High HA, Scalable, Durable, Non-durable, >1, <1). При использовании дополнительных модулей (или их самостоятельной реализации) можно реализовать произвольную логику по работе с задачами. Основные недостатки: отсутствие готовых механизмов переключения мастера (может быть решено при помощи etcd/zookeeper), отсутствие синхронной репликации (не позволяет реализовать одновременно автофейловер и ≈1). Имеются [альтернативные](https://github.com/moonlibs/xqueue) реализации
+ C/Lua.
+ Почти линейно масштабируется.
+ Хорошая производительность single node (20krps)
+ Конфигурируемые топологией durability и HA
+ Низкое потребление CPU, высокое потребление ресурсов RAM
+ хорошее поведение при переполнении (переход в RO)
+ хорошее поведение при развале кластера (легко управляемое и устраняемое). ресинк кластера выполняется за секунды
+ Система для построения производительного решения с заданными характеристиками по надёжности и доступности и произвольной дополнительной логикой

5. Brokerless. Единственный более менее популярный пример — [ZeroMQ](https://zeromq.org/). Представляет из себя инструмент в виде набора библиотек и подходов для построения собственного data-flow. Её иногда называют сокетами на стероидах. Разработка с использованием ZMQ требует высоких компетенций. Не может выступать в роли очереди "взял, поставил — работает".

6. Cloud based. Пример: Amazon SQS. Для потребителя является наиболее удобным вариантом, т.к. является масштабируемым и надёжным, cloud-native вариантом с гарантией доставки ≈1 (>1).

* https://dzone.com/articles/exploring-message-brokers
* https://medium.com/linagora-engineering/how-to-choose-a-message-queue-247dde46e66c
* https://stackshare.io/message-queue