Сравнение Kafka и NATS для обработки сообщений

В распределенной архитектуре связь между системами формирует основу всей инфраструктуры. Производительность, масштабируемость и надежность инфраструктуры во многом зависят от того, как события/сообщения/данные обмениваются и сохраняются.

Kafka и NATS — два популярных инструмента для обработки потоковых данных и сообщений. У них разные архитектуры и разные характеристики производительности. Они подходят для конкретных случаев использования. В этой статье мы сравним функции NATS с Kafka и объясним случаи использования, которые я рассматривал на работе.

1. Архитектура и сложность

NATS

NATS инфраструктура имеет два основных компонента:

Основной NATS

Основной NATS — это базовая структура сообщений. Она поддерживает Publish-Subscribe (позволяет сообщениям транслироваться нескольким подписчикам), Request-Reply (обеспечивает синхронную связь) и Группы очередей (облегчает распределение нагрузки между несколькими подписчиками в группе).

Она разработана для простоты, низкой задержки, высокой производительности и масштабируемости. Она отлично работает в сценариях, требующих низкой задержки и высокой пропускной способности. Однако только Основной NATS обеспечивает лишь ненадежную доставку, что означает, что сообщения доставляются только активным подписчикам. Данные будут потеряны, если подписчики офлайн. Основной NATS — хороший вариант, когда скорость и масштаб важнее долговечности.

JetStream

JetStream добавляет возможности сохранения данных к Core NATS. Это помогло обеспечить долговечность и надежность сообщений. Он позволяет сохранять сообщения или события (на диск или в память) и воспроизводить их. Сохраненные сообщения могут быть воспроизведены новым или восстанавливающимся подписчикам. С JetStream пользователи получают дополнительные функции:

1. Сохранение потоков: Как долго сообщения сохраняются. Это может основываться на размере, времени или лимитах потребителей.
2. Долговечность потребителей: Позволяет потребителям продолжать с того места, где они остановились.
3. Подтверждение сообщений: Это обеспечивает надежность доставки.

JetStream добавляет уровень сложности к Core NATS. Однако это приносит важную функцию поддержки сценариев гарантированной доставки, сохранения и воспроизводимости.

Kafka

Kafka — это распределенная система обмена сообщениями, построенная на архитектуре брокеров на основе журналов. Данные в Kafka организованы в Темы и могут иметь несколько разделов. Потребители подключены к этим разделам. Эта архитектура позволяет Kafka параллелизовать потребление сообщений для одной темы. Данные добавляются к теме/разделам последовательно. Kafka гарантирует порядок в разделе. В кластере Kafka может быть много брокеров, каждый из которых управляет списком тем и разделов. Для достижения высокой доступности и предотвращения потери данных Kafka полагается на фактор репликации, при котором разделы реплицируются между несколькими брокерами Kafka. Как видите, есть множество компонентов, которые необходимо управлять, чтобы достичь высокой пропускной способности, отказоустойчивости, хранения данных и горизонтальной масштабируемости. Это увеличивает архитектурную сложность Kafka.

2. Высокая доступность и производительность

NATS

Все узлы в кластере взаимосвязаны в сети, и клиент может подключаться к любому узлу. Эта конфигурация избегает единой точки отказа. Если один узел выходит из строя, клиент автоматически подключается к другим узлам без какого-либо ручного вмешательства. Это называется самовосстановлением в NATS. Узел с поддержкой JetStream распределяет потоки между всеми узлами. Потоки высоко управляемы и распределяются по нагрузке между узлами с поддержкой JetStream в рамках кластерной сети.

JetStream также поддерживает зеркалирование данных между несколькими кластерами или узлами. В JetStream для каждого потока выбираются лидеры. Репликация каждого потока может быть настроена. Все эти аспекты обеспечивают долговечность и доступность в NATS.

Kafka

Высокая доступность Kafka основана на репликации. Каждая тема может иметь одну или несколько партиций. Каждая партиция реплицируется между брокерами Kafka. Это обеспечивает избыточность данных и доступность. Kafka использует механизм репликации “Лидер-Подписчик”. Лидер отвечает за чтение и запись, а подписчик работает над репликацией данных.

Kafka поддерживает нечто, называемое ISR (In Sync Replicas), для каждой партиции. Если лидер выходит из строя, один из ISRs становится лидером. Для управления метаданными кластера и выборов лидера Kafka полагается на Zookeeper (KRaft в новых версиях).

3. Шаблоны сообщений

NATS

NATS использует сообщения на основе предметов. Это позволяет службам и потокам использовать шаблоны Pub-Sub, Request-Reply и Queue Subscriber. Предметы в NATS могут быть созданы с иерархией и подстановочными символами. Один поток NATS может хранить несколько предметов, и клиентские приложения могут использовать фильтрацию на стороне сервера, чтобы получать только интересующие предметы. Соединение в NATS двунаправленное и позволяет клиентам публиковать и подписываться одновременно. NATS также поддерживает очереди, очень похожие на RabbitMQ.

Kafka

Потоки в Kafka поддерживают Pub-sub и сообщения на основе тем. Балансировка нагрузки может быть достигнута через потребительские группы и разделение тем.

4. Гарантии доставки

NATS

NATS поддерживает различные гарантии доставки. NATS один по себе может поддерживать гарантию доставки “как минимум один раз”. Серверы NATS с включенным JetStream могут поддерживать дополнительные два типа гарантий. Это гарантии “как минимум один раз” и “ровно один раз”. NATS может отправлять ‘подтверждения’ отдельно по каждому сообщению. Пожалуйста, обратитесь к официальной документации NATS для различных типов ‘подтверждений’, которые он поддерживает. В зависимости от типа ‘подтверждения’ NATS может повторно доставлять сообщения.

Kafka

Kafka поддерживает гарантии как минимум один раз и ровно один раз. Порядок сообщений гарантирован на уровне раздела. Глобальная упорядоченность в Kafka невозможна.

5. Сохранение и устойчивость сообщений

NATS

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

Kafka

КАФКА поддерживает только хранение на основе файлов. Сообщения могут быть воспроизведены с последнего, первого или определенного смещения. В КАФКА поддерживается компактация журнала.

6. Языки и платформа

NATS

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

Kafka

Восемнадцать известных типов клиентов. Серверы Kafka могут работать на платформах, поддерживающих JVM.

Сценарии использования

Сценарий использования 1

Требования

У нас есть платформа данных с потоковым конвейером. Платформа использует движок Apache Flink для потоковой обработки в реальном времени и Apache Beam для написания конвейера аналитики. Ниже приведены основные требования:

1. Высокая пропускная способность и низкая задержка обработки сообщений
2. Поддержка контрольных точек и управление обратным давлением
3. Обработка сообщений размером в мегабайты
4. Надежность и сохранение сообщений

Сравнение

Преимущества Кафкиs:

• Высокая пропускная способность
• Хранение данных с настраиваемыми политиками удержания и репликация данных для обеспечения отказоустойчивости
• Поддержка хотя бы одной гарантии доставки сообщений
• Чтение сообщений с самого раннего/последнего/определенного смещения
• Подтверждения на стороне сервера для надежной доставки
• Обработка массовых потоков данных и сообщений большого размера
• Поддержка темы компакции

Недостатки Кафки:

• Высокая загрузка ресурсов. Наш кластер был локальным, и у нас были ограничения по ресурсам
• Kafka работает только в режиме практически реального времени

Преимущества NATS:

• Высокая производительность при минимальном использовании ресурсов. Наш кластер находится локально и имеет ограничения по ресурсам
• Поддержка хотя бы одного раза. Мы искали гарантию хотя бы одного раза
• Обработка сообщений с низкой задержкой

Недостатки NATS:

• Отсутствие коннекторов для Flink/Beam, следовательно, интеграция была затруднительной
• Снижение производительности при увеличении размера сообщения

Итоговое решение

После тщательного анализа был выбран Kafka. Нам пришлось найти компромисс между использованием ресурсов и другими преимуществами, которые предлагала Kafka, особенно хорошей интеграцией с Apache Beam и Flink. Еще одним преимуществом Kafka было обработка больших размеров сообщений и обработка сообщений с высокой пропускной способностью

Сценарий использования 2

Требования

Обработка событий, генерируемых в локальном кластере, например, журналов аудита. События должны обрабатываться с низкой задержкой. И поддержка взаимодействия микросервисов. Надежность и устойчивость не были требованием. Размер сообщения был небольшим. Необходимости в аналитике по событиям не было. Мы находились в ограниченной среде. Использование ресурсов и объем памяти должны быть минимальными

Решение

Почему был выбран NATS:

• Эффективное использование ресурсов
• Обработка событий с низкой задержкой.
• Поскольку это приложение на Go, объем памяти очень низкий
• Возможность обрабатывать небольшие размеры сообщений
• Поддержка запроса-ответа, которая может помочь в коммуникации микросервисов
• Когда JetStream не настроен, сообщения не сохраняются

Почему не была выбрана Kafka:

• По умолчанию сообщения сохраняются на диске
• Использование ресурсов высокое по сравнению с NATS
• Поскольку требуется JVM, объем памяти очень высокий

Итог

Выбор между Kafka и NATS зависит от ваших конкретных требований в трех ключевых областях: Архитектура и сложность, Производительность и Масштабируемость, Гарантии доставки сообщений. Kafka идеально подходит для систем, требующих надежного потокового событий, долгосрочного хранения и передовых возможностей обработки, но она обладает большей сложностью. NATS, с другой стороны, легкий, легко управляемый и отлично справляется с сценариями низкой задержки и высокой пропускной способности с более простыми потребностями в обмене сообщениями.

При проектировании распределенной системы обмена сообщениями тщательно оцените эти области, чтобы выровнять свой выбор с целями и ограничениями вашего приложения. Как Kafka, так и NATS являются мощными инструментами, и правильный выбор будет зависеть от вашего конкретного случая использования.

Ключевые области, которые следует учитывать при выборе между Kafka и NATS:

1. Архитектура и сложность
2. Высокая доступность и производительность
3. Гарантии доставки сообщений

Кафка идеально подходит для распределенных систем, требующих потоков событий, надежного хранилища и возможностей продвинутой обработки. Однако Кафка имеет высокое потребление ресурсов и отметается большим объемом памяти. И сложность управления очень высока по сравнению с NATS.

С другой стороны, NATS является легким и простым в управлении. Низкая задержка обработки сообщений – это особенная возможность NATS.

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