CC BY
261Бумажная промышленность: Kafka против RabbitMQ. Сравнительное исследование двух отраслевых эталонных реализаций publish/subscribe
Москвичева К. С.,
2016104073@pnu.edu.ru
Долгачев М.В.,
007428@pnu. edu. ru
ФГБОУВО «Тихоокеанский государственный университет» (г. Хабаровск, Россия)
УДК 004.75
Аннотация. Цель работы - формулирование аргументов в виде целостного подхода, установление общей схемы сравнения, основанной на основных функциях pub/sub систем. Методы и объекты исследования: качественное и количественное (то есть эмпирическое) сравнение общих характеристик двух систем. Кроме того, мы также выделяем отличительные особенности каждой из этих систем. После перечисления набора сценариев использования, которые лучше всего подходят для RabbitMQ или Kafka, мы пытаемся провести читателя по таблице определения, чтобы выбрать лучшую архитектуру с учетом его/ее конкретного набора требований. Результаты: обе системы способны предоставлять результаты с низкой задержкой. В самой базовой настройке RabbitMQ превосходит пропускную способность Kafka. И Kafka, и RabbitMQ могут масштабироваться дальше, разделяя потоки на несколько узлов. В RabbitMQ для этого требуется дополнительная специальная логика. Выводы. В этой статье мы формулируем аргументы в рамках целостного подхода. Основываясь на структуре мы провели качественное и количественное сравнение общих черт двух систем. В дополнение к общим функциям мы перечислили важные особенности, которые уникальны для любой из двух систем. Далее мы рассмотрели ряд классов вариантов использования, которые лучше всего подходят для Kafka или RabbitMQ, а также предложили варианты для комбинированного использования двух систем.
Ключевые слова: системы публикации / подписки, брокеры сообщений, Apache Kafka, RabbitMQ, файлы журналов, AMQP, производительность, надежность.
Industry Paper: Kafka versus RabbitMQ. A comparative study of two industry reference publish/subscribe
implementations
Moskvicheva K.S.,
2016104073@pnu.edu.ru
Dolgachev M.V.,
007428@pnu.edu.ru
Pacific National University (Khabarovsk, Russia)
UDC 004.75
Annotation. The purpose of the work is to formulate arguments in the form of a holistic approach, to establish a general comparison scheme based on the main functions of pub / sub systems. Research methods and objects:
qualitative and quantitative (i.e. empirical) comparison of the general characteristics of two systems. In addition, we also highlight the distinctive features of each of these systems. After listing the set of use cases that are best for RabbitMQ or Kafka, we try to walk the reader through the definition table to select the best architecture based on his / her specific set of requirements. Results: Both systems are capable of delivering low latency results. In its most basic setup, RabbitMQ outperforms Kafka throughput. Both Kafka and RabbitMQ can scale further by splitting threads across multiple nodes. In RabbitMQ, this requires additional custom logic. Conclusions: In this article, we formulate arguments in a holistic manner. Based on the structure, we made a qualitative and quantitative comparison of the common features of the two systems. In addition to common features, we have listed important features that are unique to either of the two systems. Next, we looked at a number of use case classes that work best for Kafka or RabbitMQ, and suggested options for using the two systems in combination.
Keywords: publish / subscribe systems, message brokers, Apache Kafka, RabbitMQ, log files, AMQP, performance, reliability.
Введение
Интернет значительно изменил масштаб распределенных систем. Распределенные системы теперь включают тысячи объектов, потенциально распределенных по всему миру, местоположение и поведение которых могут сильно различаться на протяжении всего жизненного цикла системы. Эти ограничения подчеркивают необходимость в более гибких моделях и системах связи, отражающих динамический и независимый характер приложений. Индивидуальные двухточечные и синхронные коммуникации приводят к жестким и статическим приложениям и делают разработку динамических крупномасштабных приложений обременительной [8]. Чтобы снизить нагрузку на разработчиков приложений, связь между различными объектами в таких крупномасштабных условиях должна быть обеспечена с помощью специальной инфраструктуры промежуточного программного обеспечения, основанной на адекватной схеме связи. Схема взаимодействия «pub/sub» обеспечивает слабосвязанную форму взаимодействия, необходимую в таких крупномасштабных условиях [8].
молодёжной науки
Youth Science Forum Journal
ТЕХНИЧЕСКИЕ НАУКИ
Apache Kafka [1] и RabbitMQ [4] - две популярные общедоступные и коммерчески поддерживаемые системы pub/sub с открытым кодом (от Confluent Inc. и Pivotal), которые существуют уже почти десять лет и получили широкое распространение в корпоративных компаниях.
Несмотря на общие черты, эти две системы имеют разную историю и цели проектирования, а также разные особенности. Например, они следуют разным архитектурным моделям: в RabbitMQ производители публикуют пакеты сообщений с ключом маршрутизации в сеть обменов, где принимаются решения о маршрутизации, и попадают в очередь, в которой потребители могут получать сообщения с помощью push-уведомлений. (предпочтительно) или вытяжной механизм. В Kafka производители публикуют пакеты сообщений в журнал добавления на диске, который зависит от темы. Любое количество потребителей может извлекать сохраненные сообщения через механизм индекса.
В первом разделе мы выделяем основные концепции парадигмы pub/sub, ее требуемые и желаемые гарантии, а также некоторые из ее реализаций.
Основная цель этого раздела - установить общую структуру/язык, который будет использоваться в остальной части статьи. Знающие читатели могут его пропустить.
Во втором разделе мы даем краткое описание систем Apache Kafka и RabbitMQ. В частности, мы смотрим на историю/контекст их создания, их основные цели дизайна, а также некоторые важные детали их реализации и оптимизации. Каждый из этих аспектов может помочь нам получить более полное представление об этих системах и, следовательно, лучше объяснить их различия.
В третьем разделе мы даем качественное сравнение Kafka и RabbitMQ по ряду общих функций pub/sub.
Следует отметить, что для простоты мы рассматриваем только последние стабильные выпуски двух систем (например, Kafka 0.10 и RabbitMQ 3.5).
В предыдущих разделах мы рассмотрели общие функции Kafka и RabbitMQ. Однако эти две системы также имеют свои отличительные особенности. Знание таких функций может быть важным фактором при принятии решения о выборе одного из двух. Поэтому ниже мы даем краткое описание таких функций.
Учитывая популярность этих двух систем и тот факт, что обе они позиционируются как системы pub/sub, на соответствующих онлайн-форумах часто задаются два вопроса: как они соотносятся друг с другом и какую из них использовать?
Хотя в Интернете можно найти множество специальных рекомендаций (некоторые из которых основаны на точных тестах), мы обнаружили, что их трудно обобщить на другие приложения, и считаем, что они не соответствуют обсуждаемым системам. В частности, (i) более широкий контекст такого анализа, например, качественное сравнение или отличительные особенности каждой системы, часто упускается из виду, (ii) из-за быстрых темпов развития, в частности, в случае с Кафкой, некоторые из сообщенных результатов устарели и больше не действительны, и (iii) трудно сравнивать результаты различных экспериментов.
Основная часть
1. Итория: pub/sub систем
1.1. Основные функции
Pub/sub - это парадигма распределенного взаимодействия, хорошо адаптированная для развертывания масштабируемых и слабосвязанных систем.
Разделение издателей и подписчиков, возможно, является наиболее фундаментальной функцией системы pub/sub. Eugster et al. [8] описали разделение, которое обеспечивает схема координации публикаций и субподрядчиков, по следующим трем параметрам:
- Разделение сущностей: издателям и потребителям не нужно знать друг о друге. Инфраструктура pub/sub завершает взаимодействие посередине.
- Временная развязка: взаимодействующим сторонам не нужно активно участвовать во взаимодействии или, даже более того, включаться одновременно.
- Разделение синхронизации: при взаимодействии между производителем или потребителем и инфраструктурой pub/sub не требуется синхронно блокировать потоки выполнения производителя или потребителя, что позволяет максимально использовать ресурсы процессора как у производителей, так и у потребителей.
Еще одна основная функция систем pub/sub - это логика маршрутизации (также известная как модель подписки), которая определяет, попадет ли и в каком месте пакет, исходящий от производителя, у потребителя. Различные способы указания интересующих событий привели к нескольким схемам подписки, которые уравновешивают гибкость и производительность. Два основных типа логики маршрутизации:
- Подписка на основе темы характеризуется тем, что издатель статически маркирует сообщение набором тем, которые затем могут быть очень эффективно использованы в операции фильтрации, которая определяет, какое сообщение отправляется потребителю. Большинство систем позволяют использовать в названиях тем подстановочные знаки.
- Подписка на основе содержимого не требует, чтобы производитель явно пометил сообщение контекстом маршрутизации. Все поля данных и метаданных сообщения могут использоваться в условии фильтрации. Потребители подписываются на выборочные события, задавая фильтры на языке подписки. Оценка этих сложных фильтров требует больших затрат на обработку.
1.2. Гарантии качества обслуживания
В дополнение к вышеупомянутым основным функциям систем pub/sub они также определяются относительно большим набором требуемых и желаемых гарантий, которые обычно называются гарантиями качества обслуживания (QoS) [9, 11, 14].
Следует отметить, что важным допущением в этом разделе является распределенная природа современных систем pub/sub. Распространение необходимо для обеспечения масштабируемости. Однако это приводит к ряду технических проблем, которые делают проектирование и реализацию распределенного хранения, индексации и вычислений деликатным вопросом [7].
Таблица 1 - Гарантии качества обслуживания
Характеристика Определение Дополнительная информация
Правильность Гарантии доставки ◦ не более одного раза: в этом режиме при нормальных условиях работы пакеты будут доставляться, но при сбое может произойти потеря пакетов. ◦ хотя бы один раз: в этом режиме система будет следить за тем, чтобы пакеты не терялись. ◦ ровно один раз (гарантирует отсутствие потерь и дубликатов): для этого требуется дорогостоящая сквозная двухфазная фиксация.
Продолжение табл. 1
Гарантии при заказе ◦ без заказа: отсутствие гарантии заказа -идеальный случай для производительности. ◦ упорядочение по разделам: в этом режиме можно определить один раздел для каждого потока сообщений, который необходимо обработать по порядку. ◦ глобальный порядок: из-за накладных расходов на синхронизацию введение гарантии глобального упорядочения по разным каналам требует значительных дополнительных ресурсов и может серьезно снизить производительность.
Доступность Способность системы максимально увеличить время безотказной работы. Могут быть обнаружены сбои и инициированы действия по исправлению.
Транзакции Используются для группировки сообщений в элементарные единицы. Производитель, который публикует несколько семантически связанных сообщений, может не захотеть, чтобы потребители видели частичную последовательность сообщений, если это не удается во время передачи.
Масштабируемость Относится к способности системы непрерывно развиваться, чтобы поддерживать растущее количество задач. В случае систем pub/sub может иметь различные параметры, например, потребители/производители, темы и сообщения.
Эффективность Двумя общими показателями эффективности являются задержка и пропускная способность. В любой транспортной архитектуре задержка пакета/сообщения определяется последовательным конвейером, через который он проходит. Пропускная способность транспортной архитектуры - это количество пакетов в единицу времени, которые могут быть переданы между производителями и потребителями. Для простого конвейера пропускная способность и задержка обратно пропорциональны.
1.3. Реализации
Большое количество фреймворков и библиотек можно отнести к категории имеющих функциональность обмена сообщениями pub/sub. Один из подходов к их классификации состоит в том, чтобы расположить их по спектру сложности, который начинается с легких систем с меньшим количеством функций и заканчивается сложными системами с богатым набором функций.
На легкой стороне спектра мы используем ZeroMQ, Finagle, Apache Kafka и т. Д. Более тяжелые примеры включают реализации Java Message Service (JMS), такие как ActiveMQ, JBOSS Messaging, Glass и т.д. AMQP 0.9, популярный и стандартизованный протокол pub/sub имеет несколько реализаций, таких как RabbitMQ, Qpid, HornetQ и т. д. Еще более сложными и многофункциональными являются распределенные RPC-фреймворки, которые включают pub/sub, например, MuleESB, Apache ServiceMix, JBossESB и т.д.
2. Высокоуровневое описание
2.1. Apache Kafka
Kafka изначально создавалась в LinkedIn как платформа для централизованной конвейерной обработки событий, заменяющая разрозненный набор систем интеграции точка-точка [10].
Kafka разработан для обработки высокой пропускной способности (миллиарды сообщений) [10]. В его конструкции особое внимание было уделено эффективной работе с несколькими потребителями одного и того же потока, которые читают с разной скоростью (например, потоковая или пакетная).
Полученная в результате система представляет собой масштабируемую систему обмена сообщениями с подпиской на публикацию, разработанную на основе распределенного журнала фиксации [17]. Высокая пропускная способность - одно из преимуществ конструкции систем агрегирования журналов по сравнению с большинством систем обмена сообщениями [10]. Данные записываются в набор журналов без немедленного сброса на диск, что позволяет использовать очень эффективные шаблоны ввода-вывода.
Рисунок 1. Архитектура Kafka
Рисунок 2. Архитектура RabbitMQ (AMQP)
молодёжной науки
Youth Science Forum Journal
ТЕХНИЧЕСКИЕ НАУКИ
На рисунке 1 показана высокоуровневая архитектура Kafka. Производители отправляют сообщения в тему Kafka, которая содержит ленту всех сообщений этой темы. Каждая тема распределена по кластеру брокеров Kafka, причем каждый брокер размещает ноль или более разделов каждой темы. Каждый раздел представляет собой упорядоченный журнал с упреждающей записью сообщений, сохраняемых на диске. Все темы доступны для чтения любому количеству потребителей, а дополнительные потребители имеют очень низкие накладные расходы.
По сравнению с традиционными системами pub/sub, понятие потребителя в Kafka обобщено как группа взаимодействующих процессов, выполняемых как кластер. Каждое сообщение в теме доставляется одному потребителю в каждой из этих групп потребителей. В результате раздел является единицей параллелизма темы и контролирует максимальный параллелизм потребителей. Более того, поскольку каждый раздел имеет единственного потребителя в своей группе, потребляющий процесс может лениво записывать свою собственную позицию, вместо того, чтобы сразу отмечать каждое сообщение, что важно для производительности. Если процесс выйдет из строя до того, как позиция будет записана, он просто повторно обработает небольшое количество сообщений, давая семантику доставки хотя бы один раз.
Наконец, стоит отметить, что изначально Kafka сильно полагалась на Apache Zookeeper [11] для реализации своей логики уровня управления, но с каждым выпуском зависимость от Zookeeper снижается. Примерно в версии 0.[8].2 управление потребителями было передано от Zookeeper координатору внутри брокера. Zookeeper по-прежнему управляет контроллерами и кластерами, темами и разделами, синхронизированной репликацией данных и статическими конфигурациями, такими как квоты и списки контроля доступа.
Таким образом, для удовлетворения требований к высокой пропускной способности Kafka отошел от классических принципов систем обмена сообщениями несколькими способами:
- Он разделяет данные таким образом, что производство, посредничество и потребление данных обрабатываются кластерами машин, которые можно постепенно масштабировать по мере увеличения нагрузки. Kafka гарантирует, что сообщения из одного раздела доставляются потребителю по порядку. Однако нет никакой гарантии, что сообщения поступают из разных разделов.
- Сообщения не «выталкиваются» из журнала, но могут быть воспроизведены потребителями (например, при обработке ошибок приложения-потребителя).
- Кроме того, состояние читателя сохраняется только у потребителей, подразумевая, что удаление сообщения может быть основано только на настроенной вручную политике хранения, выраженной либо в количестве сообщений, либо в возрасте сообщения.
- Кроме того, он также применяет ряд очень эффективных методов оптимизации, в первую очередь:
- Пакетирование используется на всех этапах конвейера (производство, посредничество и потребление) со значительным увеличением пропускной способности, в некоторых случаях более чем в 50 раз [10].
- Он полагается на постоянные структуры данных и кэш страниц ОС. Стратегия упреждающего чтения операционной системы очень эффективна для оптимизации линейного чтения данных потребителей, которые последовательно используют фрагменты файлов журнала. Буферизация записей естественным образом заполняет этот кеш, когда сообщение добавляется в журнал, и это в сочетание с тем, что большинство потребителей не отстают, означает очень высокий коэффициент попадания в кеш, что делает чтение почти бесплатным с точки зрения дискового ввода-вывода.
молодёжной науки
Youth Science Forum Journal
ТЕХНИЧЕСКИЕ НАУКИ
2.2. RabbitMQ
RabbitMQ в первую очередь известен и используется как эффективная и масштабируемая реализация протокола расширенной очереди сообщений (AMQP). Следовательно, ниже мы сначала дадим краткое введение в AMQP, а затем кратко объясним его реализацию RabbitMQ (и расширения).
2.2.1. AMQP
AMQP возник из потребности во взаимодействии различных промежуточных программ асинхронного обмена сообщениями. Более конкретно, хотя для синхронного обмена сообщениями существовали различные стандарты промежуточного программного обеспечения (например, IIOP, RMI, SOAP и т. Д.), Этого не было в мире асинхронного обмена сообщениями, однако, в котором существует несколько продуктов, использующих свои собственные закрытые протоколы. (например, IBM Websphere MQ и Microsoft Message Queuing) [16]. Спецификация службы сообщений Java (JMS) была, пожалуй, самым известным стандартом в мире асинхронного обмена сообщениями. Однако это просто стандарт интерфейса и не определяет стандартный протокол. Кроме того, JMS была ограничена Java, которая является только одной жизнеспособной технологией реализации в области промежуточного программного обеспечения обмена сообщениями.
То, что сейчас известно как AMQP, возникло в 2003 году в JPMorgan Chase. С самого начала AMQP задумывался как открытая совместная работа. JPMorgan Chase и Red Hat создали Apache Qpid. Независимо, RabbitMQ был разработан на Erlang компанией Rabbit Technologies.
Примерно в 2011 году стандарт AMQP отделился от широко распространенной функциональности v0.9.1 (небольшая вариация версии 0.9 [15]) с созданием AMQP 1.0.
Дизайн AMQP был основан на строгих требованиях к производительности, масштабируемости и надежности со стороны финансового сообщества. Однако его использование выходит далеко за рамки индустрии финансовых услуг и в целом применимо для решения широкого круга задач промежуточного программного обеспечения.
Как показано на рисунке 2, AMQP использует модульный подход, разделяя задачу брокера сообщений между обменами и очередями сообщений [16]:
- Обмен - это, по сути, маршрутизатор, который принимает входящие сообщения от приложений и на основе набора правил или критериев решает, в какие очереди направлять сообщения.
- Очередь сообщений хранит сообщения и отправляет их получателям сообщений. Надежность среды хранения полностью зависит от реализации очереди сообщений - очереди сообщений обычно хранят сообщения на диске до тех пор, пока они не будут доставлены, - но также возможны очереди, в которых сообщения хранятся исключительно в памяти.
Объединение обменов и очередей сообщений - это привязки, которые определяют правила и критерии, по которым происходит обмен маршрутными сообщениями. В частности, приложения создают привязки и связывают их с очередями сообщений, тем самым определяя сообщения, которые обменники доставляют в каждую очередь.
В соединении AMQP каналы могут использоваться для изоляции потоков сообщений друг от друга. В многопоточной среде отдельным потокам обычно назначается собственный канал.
2.2.2. Реализация RabbitMQ и расширения AMQP
RabbitMQ по умолчанию поддерживает AMQP 0.9.1 и может поддерживать AMQP 1.0 через плагин.
RabbitMQ выходит за рамки гарантий AMQP по ряду аспектов: он имеет более эффективный механизм подтверждения для издателей, имеет более четко определенное транзакционное
молодёжной науки
Youth Science Forum Journal
ТЕХНИЧЕСКИЕ НАУКИ
поведение, лучше поддерживает асинхронную пакетную передачу, поддерживает определенную степень связи между производителями и потребителями (т. Е. Поток контроль). Подробный список расширений см. В [2].
RabbitMQ реализован в Erlang, что означает, что он использует модель акторов в качестве примитива связи между легковесными процессами Erlang. Таким образом, он получает выгоду от инфраструктуры Erlang Open Telecom Platform (OTP), которая значительно облегчает создание и управление архитектурами высокой доступности. Erlang и модель акторов являются основными причинами масштабируемости RabbitMQ с точки зрения количества тем и очередей и обеспечивают возможности кластеризации с очень низкими накладными расходами на проектирование.
По сравнению с Kafka RabbitMQ намного ближе к классическим системам обмена сообщениями. В частности, RabbitMQ: (i) берет на себя большую часть бухгалтерского учета потребления, (ii) его основная цель проектирования - обработка сообщений в памяти DRAM, (iii) логика очереди оптимизирована для пустых или почти пустых очередей и производительность значительно ухудшается, если сообщениям позволяют накапливаться [5].
3. Общие характеристики: качественное сравнение
3.1. Временная развязка
Обе системы можно использовать для буферизации большого пакета сообщений, который необходимо обработать позже или с гораздо меньшей скоростью, чем создается.
С этой целью RabbitMQ будет хранить сообщения в DRAM как можно дольше, но как только доступная DRAM будет полностью израсходована, RabbitMQ начнет сохранять сообщения на диске без наличия копии в DRAM, что серьезно скажется на производительности. Kafka, с другой стороны, был специально разработан с учетом требований к различным уровням потребления и, следовательно, гораздо лучше подходит для обработки более широкого масштаба временной развязки.
3.2 Логика маршрутизации
RabbitMQ наследует логику маршрутизации AMQP и, следовательно, может быть очень сложным. Stock RabbitMQ уже обеспечивает ряд различных типов обмена, в частности: (i) очень гибкий тематический обмен (типа topic), который поддерживает составную маршрутизацию на основе тем «abc» с поддержкой подстановочных знаков («*» для одной части и «#» для произвольного количества частей), (ii) обмен на основе содержимого (заголовка типа).
Поскольку RabbitMQ предоставляет API для создания дополнительных обменов, логика маршрутизации может быть любой, что вам нужно. Например, сообщество RabbitMQ предоставило дополнительные определения обмена, наиболее важно поддержку балансировки нагрузки [3].
Еще одна важная и полезная функция RabbitMQ - это альтернативный обмен, который позволяет клиентам обрабатывать сообщения, которые обмен не может маршрутизировать (то есть либо потому, что не было связанных очередей, либо соответствующих привязок).
В Kafka выбор более ограничен: он поддерживает базовую форму тематической маршрутизации. В частности, производитель контролирует, в какой раздел он публикует сообщения. Это может быть выполнено случайным образом (например, с балансировкой нагрузки) или с помощью некоторой функции разделения, позволяя пользователю указать ключ разделения и использовать его для хеширования раздела. Функция разделения может быть изменена пользователем.
3.3. Гарантии доставки
RabbitMQ и Kafka различаются своим представлением о семантике хотя бы один раз. Поскольку отдельные пакеты из пакета могут дать сбой, восстановление после сбоев может повлиять на порядок пакетов. В зависимости от приложения порядок может быть важным, поэтому имеет смысл разделить его на:
(1) хотя бы один раз без сохранения порядка: Кафка не может сохранять порядок при отправке в несколько разделов.
(2) хотя бы один раз с сохранением порядка: RabbitMQ сортирует сообщения при записи их в структуры очереди, что означает, что потерянные сообщения могут быть правильно доставлены по порядку без необходимости повторной отправки полного пакета, который потерял одно или более сообщений. Kafka сохранит порядок при условиях, указанных в разделе 4.4.
Следует отметить, что при использовании стандартного AMQP 0.9.1 единственный способ гарантировать, что сообщение не будет потеряно, - это использовать излишне тяжелые транзакции, которые резко снижают пропускную способность. Чтобы исправить это, в RabbitMQ был введен механизм подтверждения, который имитирует механизм подтверждения потребителя, уже присутствующий в протоколе.
Гарантия доставки пакета включает концепцию «передачи права собственности» между различными компонентами архитектуры. Гарантия не является абсолютной: мы вводим понятие вероятности отказа во времени и интенсивности отказов X отдельных компонентов и всей цепочки передачи пакетов. Вероятность и частота отказов могут быть уменьшены за счет репликации.
Рисунок 3. Надежный перевод
В дальнейшем отказы производителей и потребителей выходят за рамки (мы предполагаем X = 0).
Сценарии для RabbitMQ и Kafka в основном отвлекаются от генерации подтверждения издателя, взаимодействия с потребителем и удаления сообщений.
- t1, производитель владеет сообщением для пересылки и доставляет его в RabbitMQ/Kafka.
- t2, RabbitMQ «обрабатывает» сообщение; фактическая логика этой обработки зависит от конкретного случая: (i) для немаршрутизируемых сообщений брокер выдаст подтверждение, как только обмен подтвердит, что сообщение не будет направлено ни в какую очередь, (ii) для маршрутизируемых сообщений подтверждение выдается после сообщение было принято всеми очередями, (iii) для постоянных сообщений, направленных в долговременные очереди, это означает сохранение на диск, и (iv) для зеркальных очередей это означает, что все зеркала приняли сообщение; Kafka добавляет сообщение в соответствующий раздел журнала добавления на главном узле брокера A и, возможно, на избыточном узле брокера B
- t3, согласованный ASK от узла A (и, если применимо, B) отправляется производителю -право собственности теперь переходит к RabbitMQ/Kafka, и производитель может удалить сообщение
молодёжной науки
Youth Science Forum Journal
ТЕХНИЧЕСКИЕ НАУКИ
- t4, потребитель получает сообщение от RabbitMQ/Kafka
- t5 [зависит от RabbitMQ] потребитель отправляет ASK узлу A (и, если применимо, B) -право собственности теперь переходит к потребителю, и брокер может удалить сообщение. Обратите внимание, что обычно каждый потребитель будет читать из выделенной очереди, поэтому брокер сохранит владение сообщениями, которые должны быть отправлены нескольким потребителям, если все ACKS еще не получены.
- t5 [специфично для Kafka] Kafka не сохраняет состояние, поэтому не имеет возможности понять, что право собственности перешло к потребителю. Он будет удерживать сообщение до истечения настроенного тайм-аута (обычно несколько дней).
RabbitMQ улучшает AMQP и предлагает возможность публиковать пакеты сообщений с отдельными ответами ASK / NACK, указывающими, что сообщение благополучно попало на диск (т.е. fsynced).
Поведение подтверждения Kafka может быть выбрано как 0 для максимального усилия, 1, чтобы сигнализировать производителю, когда лидер получил пакет, но не зафиксировал его на диске (имеет значение при работе в режиме репликации, поскольку в противном случае пакет может потеряться) или -1, чтобы сообщить производителю, когда кворум получил пакет, но не зафиксировал его на диске (не должно быть проблемой, если все реплики не работают в одной среде, что означает, что все они могут выйти из строя сразу, вызвав например, из-за сбоя питания).
При работе без репликации Kafka в своей конфигурации по умолчанию не ждет с отправкой ASK, пока не произойдет fsync, и поэтому сообщения могут быть потеряны в случае сбоя. Это может быть изменено конфигурацией за счет уменьшения
пропускная способность.
3.4. Гарантии заказа
RabbitMQ сохранит порядок для потоков 1, используя один канал AMQP. Он также переупорядочивает повторно передаваемые пакеты внутри своей логики очереди, чтобы потребителю не нужно было переупорядочивать буферы. Это означает, что если балансировщик нагрузки будет использоваться перед RabbitMQ (например, для достижения масштабируемости того, что может быть выполнено внутри Kafka с помощью разделов), пакеты, которые покидают балансировщик нагрузки на разных каналах, больше не будут иметь отношения упорядочения.
Kafka сохранит порядок только внутри раздела. Более того, внутри раздела Kafka гарантирует, что пакет сообщений либо все пройдут, либо все вместе не пройдут. Однако, чтобы сохранить межпартийный порядок, производитель должен гарантировать выполнение не более 1 запроса на производство, что повлияет на максимальную производительность.
3.5. Доступность
И RabbitMQ, и Kafka обеспечивают доступность через репликацию. Кластеры RabbitMQ можно настроить для репликации всей информации обмена и привязки. Однако он не будет автоматически создавать зеркальные очереди (терминология RabbitMQ для реплицированных очередей) и потребует явной настройки во время создания очереди.
Для Kafka доступность требует запуска системы с достаточно высоким коэффициентом репликации.
Как указано в теореме CAP [9], в любой архитектуре, основанной на репликации, проблемы разделения мозга могут возникнуть из-за сбоев в разделах сети. Для более подробного описания моделей доступности (а также анализа теорем CAP) Kafka и RabbitMQ см. Соответствующие эпизоды в серии статей Джепсена [ 19, 20].
молодёжной науки
Youth Science Forum Journal
ТЕХНИЧЕСКИЕ НАУКИ
3.6 Транзакции
Транзакции AMQP применяются только к pub/sub. RabbitMQ также сделал отказ транзакционным. Со стороны потребителя подтверждения являются транзакционными, а не потреблением самих сообщений. AMQP гарантирует атомарность только тогда, когда транзакции связаны с одной очередью. RabbitMQ не предоставляет гарантий атомарности даже в случае транзакций, включающих только одну очередь, например, сбой во время фиксации может привести к тому, что подмножество публикаций транзакции появится в очереди после перезапуска брокера. Обратите внимание, что это не транзакции в строгом смысле ACID, поскольку требуется некоторое взаимодействие с издателем или потребителем. Возьмите, например, производитель, выпускающий партию. Если какое-либо из сообщений не удается, производитель получает возможность повторно опубликовать эти сообщения, и RabbitMQ вставит их в очередь по порядку. После чего издатель получает уведомление о том, что сообщения о сбое действительно были доставлены и могут считать транзакцию завершенной. Kafka в настоящее время не поддерживает транзакции.
3.7 Многоадресная передача
Приложениям часто требуется отправлять одну и ту же информацию нескольким адресатам.
RabbitMQ поддерживает многоадресную рассылку, предоставляя выделенную очередь для каждого отдельного потребителя. В результате единственное влияние на систему заключается в увеличении количества привязок для поддержки этих отдельных очередей. RabbitMQ имеет представление о том, какие потребители уже приняли на себя ответственность за каждое сообщение, поэтому может легко решить, когда он может удалить сообщение из своей системы. В случаях разветвления RabbitMQ хранит индексы и метаданные для каждой очереди, но только одну копию тела сообщения для всех очередей.
В Kafka в брокерах поддерживается только одна копия сообщений в теме (в настройках без репликации); однако логика многоадресной рассылки полностью выполняется на стороне потребителя. Каждый потребитель может получать сообщения из Kafka на основе индекса сообщения. Kafka не знает, когда все потребители стали владельцем сообщения, поэтому он просто хранит сообщение в течение настраиваемого времени или размера.
3.8. Динамическое масштабирование
Для RabbitMQ добавление дополнительных узлов к работающим кластерам или удаление узла из кластера хорошо поддерживается. Эти дополнительные узлы смогут стать главными для вновь созданных очередей и будут принимать каналы, позволяющие публиковать на любом обмене или потреблять из любой очереди, но не могут использоваться для перераспределения назначений главной очереди существующих очередей без ручного вмешательства. Добавление узлов в кластер RabbitMQ прозрачно для потребителей - они по-прежнему предпочтительно потребляют из основной очереди, хотя использование из любого другого узла кластера работает за счет дополнительной внутренней сетевой нагрузки, поскольку пакеты находятся в главная очередь.
В Kafka при добавлении новых узлов в кластер пользователь может решить переместить существующие разделы на новый узел. В этом случае на новом узле создается новая реплика, и как только она догонит, старую реплику раздела можно удалить. Это можно сделать онлайн, пока потребители потребляют. Добавление узлов в кластер Kafka непрозрачно для потребителей, поскольку в группе потребителей должно быть отображение разделов на потребителей. Удаление узла можно выполнить, сначала перераспределив разделы на этом узле среди остальных узлов.
Отличительные особенности Kafka и RabbitMQ представлены в таблице 2.
Таблица 2 - Отличительные особенности Kafka и RabbitMQ
Kafka RabbitMQ
Долгосрочное хранение сообщений. Сообщения удаляются либо по истечении срока хранения, либо при превышении дисковой квоты темы. Стандартизированный протокол. Он обладает более высоким уровнем взаимодействия и может легко работать другими реализациями, совместимыми с AMQP.
Повтор сообщения. Потребители могут легко воспроизводить сообщения при необходимости. Многопротокольный. Поддерживает несколько других отраслевых стандартных протоколов для публикации и использования сообщений.
Kafka Connect - это платформа для масштабируемой и надежной потоковой передачи данных между Apache Kafka и другими системами. Режимы распределенной топологии. Поддерживает федеративные обмены, имеет меньшую степень связи.
Сжатие журнала. Гарантирует, что он всегда будет сохранять по крайней мере последнее известное значение для каждого ключа сообщения в журнале данных для одного раздела темы. Комплексные инструменты управления и мониторинга. Поставляется с простым в использовании пользовательским интерфейсом управления, который позволяет пользователю отслеживать и контролировать все аспекты брокера сообщений.
Мультитенантность и изоляция. Реализует нотацию виртуальных хостов, чтобы один брокер мог размещать несколько изолированных сред .
Отслеживание потребителей. На уровне очереди он сохраняет состояние и точно знает, какие потребители и какие сообщения потребляли в любое время.
Бездисковое использование. Не требует дискового пространства для маршрутизации пакетов, если постоянство не является обязательным [6].
Управление потоком издателя. Может помешать издателям сокрушить брокера в экстремальных ситуациях.
Пределы размера очереди. Этот механизм может помочь в сценарии управления потоком, когда удаление сообщений допустимо.
ТТЬ сообщения. Сообщению может быть дано «Время жизни». Если оно останется в любой очереди дольше этого времени, оно не будет доставлено потребителю.
молодёжной науки
Youth Science Forum Journal
ТЕХНИЧЕСКИЕ НАУКИ
Заключение
В данной статье мы приводили качественное сравнение Apache Kafka и RabbitMQ. Что касается задержки, обе системы способны предоставлять результаты с низкой задержкой. В случае RabbitMQ разница между режимами доставки «не более одного раза» и «хотя бы один раз» несущественна. Для Kafka, с другой стороны, задержка увеличивается примерно вдвое для режима хотя бы один раз. Кроме того, если ему нужно читать с диска, его задержка может на порядок вырасти.
Что касается пропускной способности, в самой базовой настройке RabbitMQ превосходит пропускную способность Kafka. Однако увеличение количества разделов Kafka на одном узле может значительно улучшить его производительность, демонстрируя его превосходную масштабируемость. С другой стороны, увеличение количества производителей/каналов в RabbitMQ могло только умеренно улучшить его производительность.
И Kafka, и RabbitMQ могут масштабироваться дальше, разделяя потоки на несколько узлов. В RabbitMQ для этого требуется дополнительная специальная логика, такая как Consistent Hash Exchange [3] и Sharding Exchange [13]. В Kafka это бесплатно. Наконец, репликация сильно влияет на производительность RabbitMQ и Kafka и снижает их производительность.
Хотя аспекты эффективности очень важны, архитекторам настоятельно рекомендуется рассмотреть все другие аспекты проблемы, как описано в разделах 3 (качественное сравнение общих функций, помимо производительности) и 4 (отдельные функции), прежде чем делать выводы. Хорошим примером может служить исследование, описанное в [12] и проведенное в контексте реального приложения.
Библиографический список
1. Apache Kafka. URL https://kafka.apache.org/.
2. RabbitMQ: Protocol Extensions. URL https://www.rabbitmq.com/extensions.html.
3. Consistent Hash Exchange. URL https://github.com/rabbitmq/rabbitmq-consistent-hash-exchange.
4. RabbitMQ. URL https://www.rabbitmq.com/.
5. Sizing your Rabbits, 2011. URL https://www.rabbitmq.com/blog/2011/09/24/sizing-your-rabbits/.
6. Abarbanell T. Benchmarking RabbitMQ on Raspberry Pi, 2015. URL http://blog.abarbanell.de/raspberry/2015/05/17/benchmarking-rabbitmq-on-raspberry/.
7. Abiteboul S., Manolescu I., Rigaux P., Rousset M.-C., Senellart P. Web Data Management. Cambridge University Press, 2011.
8. Eugster P.T., Felber P.A., Guerraoui R., Kermarrec A.-M. The Many Faces of Publish/Subscribe. ACM Computing Surveys (CSUR). 2003. № 35(2). pp.114-131.
9. Gilbert S., Lynch N. Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-tolerant Web Services. Acm Sigact News. 2002. № 33(2). pp. 51-59.
10. Goodhope K. et al. Building Linkedln's Real-time Activity Data Pipeline. IEEE Data Eng. Bull. 2012. № 35(2). pp. 33-45.
11. Hunt P. et al. ZooKeeper: Wait-free Coordination for Internet-scale Systems. In USENIX Annual Technical Conference. 2010. № 8. p. 9.
12. Nannoni N. Message-oriented Middleware for Scalable Data Analytics Architectures. Master's thesis, KTH Royal Institute of Technology, Sweden, 2015.
13. Rabbitmq sharding. Sharding Exchange. URL https://github.com/rabbitmq/rabbitmq-sharding
14. Sheykh Esmaili K. et al. Changing Flights in Mid-air: A Model for Safely Modifying Continuous Queries. In Proceedings ACM SIGMOD. 2011. pp. 613-624.
15. Trieloff C. et al. A General Purpose Middleware Standard. Network Programming, SunOS. 2006. pp. 4.
16. Vinoski S. Advanced Message Queuing Protocol. IEEE Internet Computing. 2006. № 10 (6).
17. Wang G. et al. Building a Replicated Logging System with Apache Kafka. Proceedings of the VLDB Endowment. 2015. № 8 (12). pp. 1654-1655.
