Try   HackMD

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

Основные показатели, по которым можно оценивать очереди, это:

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

На сегодняшний день рынок очередей можно вкратце разделить на следующие группы:

  1. AMQP based. Подавляющее большинств решений написаны на Java и находятся под "зонтиком" Apache Foundation.
    Обладают обширной функциональностью одередей, pub/sub'а и диспетчеризации, но крайне плохо масштабируются горизонтально
    Основные игроки:
  • ActiveMQ
    • Java. Нет своего стораджа. Нет HA. (Обеспечивается стораджем).
    • посредственная производительность (~ 5krps)
    • посредственное поведение при переполнении (деградация)
    • Высокое потребление ресурсов CPU/RAM
    • Система для средней нагрузки, с RDBMS хранилищами может использоваться для высокой транзакционной целостности
  • RabbitMQ
    • Erlang. В Single режиме работает хорошо. Кластерных режимов много, но работают плохо. Может терять сообщения, может "не взлетать"
    • хорошая производительность single (~ 20krps)
    • плохое поведение при переполнении и развале кластера (отказ в обслуживании, ресинк переполненного кластера может занимать часы)
    • Высокое потребление ресурсов CPU/RAM
    • Система для средней нагрузки, "поставил и работает", без требований к HA 24/7
  1. Kafka. Изначально создаваемая, как распределённый лог транзакций, обросла обширной функциональностью очередей. С одной стороны базовая инсталляция довольно не самая простая (требует дополнительно Zookeeper), но обладает отличными эксплуатационными характеристиками за счёт удачной архитектуры. Обладает дополнительной возможностью в сравнении с классическими очередями в виде множественных потребителей на один поток данных (позволяет организовывать reactive flow)
    • Java.
    • Почти линейно масштабируется.
    • Встроенный HA за счёт использования Zookeeper, высокодоступная
    • Высокая гарантия доставки с ≈1
    • высокая производительность (100krps+, ограничена скоростью записи на диск)
    • Capacity ограничена только дисковым хранилищем
    • хорошее поведение при переполнении и развале кластера (понятное, легко управляемое и устраняемое). ресинк кластера выполняется за секунды
    • Умеренное потребление ресурсов CPU/RAM
    • Система для высоконагруженного надёжного процессинга потоков данных с возможностью использовать множественных потребителей
  2. Распределённые, децентрализованные системы. Обладают крайне высоким уровнем доступности и почти линейным масштабированием при достаточных гарантиях на надёжность доставки. Хороший пример:
  • NSQ
    • Golang.
    • Почти линейно масштабируется.
    • Высокодоступная.
    • Высочайшая производительность (800krps+ / 3 node cluster)
    • Умеренная гарантия доставки
    • Сложнореализуемая durability
    • Система для высоконагруженного онлайна 24/7, когда сообщение из потока можно потерять
  1. 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)
    • хорошее поведение при развале кластера (легко управляемое и устраняемое). ресинк кластера выполняется за секунды
    • Система для построения производительного решения с заданными характеристиками по надёжности и доступности и произвольной дополнительной логикой
  2. Brokerless. Единственный более менее популярный пример — ZeroMQ. Представляет из себя инструмент в виде набора библиотек и подходов для построения собственного data-flow. Её иногда называют сокетами на стероидах. Разработка с использованием ZMQ требует высоких компетенций. Не может выступать в роли очереди "взял, поставил — работает".

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