Mq kafka что это

Платформа потоковой передачи распределенного события на базе Scala & Java

Apache Kafka — это распределенная платформа для распределенных событий с открытым исходным кодом. Это надежный брокер по очереди и создан как внутренняя система обмена сообщениями, разработанная Linked-In

Kafka

• Overview
• Системные Требования
• Функции
• Инструкция по установке
• Часто задаваемые вопросы
• Исследовать

Обзор

Кафка — это система обмена сообщениями с открытым исходным кодом и надежный брокер в очередь. Это распределенная платформа потоковой передачи событий и имеет возможность обрабатывать большой объем сообщений. Сообщения Kafka хранятся на диске, и это позволяет отправлять сообщения из одной точки в другую. Сообщения воспроизводятся во всем кластере Kafka, чтобы предотвратить нежелательные операции, как любая потеря данных. Платформа обмена сообщениями Kafka, созданная для обработки потоковой передачи событий в реальном времени, поддавливания труб и воспроизведения данных для быстрых, масштабируемых операций. Программное обеспечение для распределенных сообщений Apache Kafka используется тысячами компаний для высокопроизводительных конвейеров данных и его интеграции с Apache Storm и Spark. Кафка предлагает высокую производительность по сравнению с брокерами сообщений и очередей, такими как ActiveMQ и Rabbitmq и т. Д. Apache Kafka является альтернативой различным системам обмена сообщениями предприятия. Он был построен как внутренняя система обмена сообщениями, разработанная Linked-In для обработки 1,4 триллиона сообщений в день. Это лучшая и подходящая платформа для реализации очередей, поскольку она повышает производительность с использованием операций ввода -вывода последовательных дисков. Это также идеальный выбор для вариантов использования больших данных, поскольку он может достичь высокой пропускной способности с ограниченным количеством ресурсов, то есть миллионы сообщений в секунду. Программное обеспечение с открытым исходным кодом Kafka имеет 19,4K GitHub Stars и 10,3K Forks.

Системные Требования

Требования к настройке программного обеспечения Apache Kafka включают:

• Java 8+
• Работник зоопарка
• Ubuntu 20.04 LTS
• Git

Функции

Некоторые из ключевых особенностей Apache Kafka перечислены ниже:

• Масштабируемость
• Большой объем
• Преобразования данных
• Отказоустойчивость
• Надежность
• Долговечность
• Производительность
• Нулевое время простоя
• Расширяемость
• Репликация
• Открытый источник

Инструкции по установке

Установите Apache Kafka на Ubuntu

Это руководство объясняет, как настроить и кафку. Ниже шаги установки предполагают, что все пакеты Depency Kafka установлены и актуальны в вашей системе. Пожалуйста, следите за этапами установки. Получить Kafka, загрузив последний релиз Kafka и извлечь его с помощью команд:

 tar -xzf kafka_2.13-2.8.0.tgz cd kafka_2.13-2.8.0 

Далее, начните окружающую среду Kafka. В вашей местной системе должна быть установлена ​​Java 8+. Выполнить следующие команды, чтобы запустить все службы в правильном порядке:

 bin/zookeeper-server-start.sh config/zookeeper.properties 

Откройте еще одну сессию терминала, и DTART Кафка брокерская служба:

 bin/kafka-server-start.sh config/server.properties 

Когда все службы успешно установили, у вас будет базовая среда Kafka, которая работает и готова к доступу. Вам нужно создать тему перед написанием вашего первого мероприятия. Откройте еще один сеанс терминала и запустите команду:

 bin/kafka-topics.sh --create --topic quickstart-events --bootstrap-server localhost:9092 

Теперь запустите клиент -консоли, чтобы написать несколько отдельных событий в тему:

 bin/kafka-console-producer.sh --topic quickstart-events --bootstrap-server localhost:9092 

Откройте еще один консольный сеанс терминала и запустите клиента Console Consumer, чтобы прочитать только что созданные события:

 bin/kafka-console-consumer.sh --topic quickstart-events --from-beginning --bootstrap-server localhost:9092 

Вы можете постоянно импортировать/экспортировать свои данные в Kafka. Используйте Ctrl-C, чтобы остановить брокера Kafka. Если вы также хотите удалить какие -либо данные из вашей локальной среды Kafka, включая любые события, которые вы создали на этом пути, запустите команду:

 rm -rf /tmp/kafka-logs /tmp/zookeeper 

Поздравляю! Вы успешно настроили платформу Apache Kafka на Ubuntu. Наслаждаться!

FAQS

Для чего используется Apache Kafka?

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

Apache Kafka бесплатно?

Apache Kafka является бесплатным, а Confluent Cloud очень дешево для небольших вариантов использования, около 1 доллара в месяц для производства, хранения и потребления GB данных.

Apache Kafka с открытым исходным кодом?

Apache Kafka-это платформа потоковой потоковой передачи с открытым исходным кодом, используемая тысячами компаний для высокопроизводительных трубопроводов, потоковой аналитики, интеграции данных и критических приложений. Исходный код приложения CEPH доступен по адресу GitHub.

На каком языке написан Кафка?

Кафка начал как проект в LinkedIn, а затем был открыт, чтобы облегчить его принятие. Он написан в Scala и Java, и он является частью программного обеспечения Apache с открытым исходным кодом.

Почему Кафка такая быстрая?

Сжатие и пакетирование данных: Kafka перечисляет данные в куски, что помогает в уменьшении сетевых вызовов и преобразовании большинства случайных записей в последовательные. Это более эффективно сжать партию данных по сравнению с сжатием отдельных сообщений.

Исследовать

В этой статье мы обсуждали об Апаче Кафке. Чтобы узнать о другом программном обеспечении очереди (MQ), посетите следующие страницы:

Почему мы используем Kafka вместо RabbitMQ: сравнение и преимущества

Делимся особенностями работы Apache Kafka и RabbitMQ, дав точный рецепт, когда и какой брокер стоит использовать.

При построении больших и сложных систем не обойтись без программных брокеров сообщений. Однако часто возникает вопрос, какой из них выбрать для того или иного проекта. Lead architect Группы «Иннотех» Александр Соляр поделился особенностями работы Apache Kafka и RabbitMQ, дав точный рецепт, когда и какой брокер стоит использовать.

Александр Соляр
Lead architect Группы «Иннотех»

В сложной корпоративной системе с гигантскими вычислительными задачами и огромными потоками событий для эффективной работы необходимо организовать распределённую архитектуру и наладить коммуникацию между её компонентами. Многие системы используют различные популярные брокеры сообщений для этих нужд, например, Apache Kafka и RabbitMQ. Разберёмся, чем отличаются эти брокеры сообщений и в каких случаях какой использовать.

Who is Mr. Apache Kafka

Apache Kafka — корпоративный стандарт работы больших высоконагруженных систем с брокером сообщений, особенно уровня business и mission critical с учётом георезервирования. Однако, для того, чтобы разобраться в преимуществах и понять недостатки продукта стоит разобраться в основах работы систем очередей в целом и механизмах их работы.

Базовая топология Kafka состоит из producer, consumer, broker и zookeeper.

За хранение ваших данных отвечает брокер (broker). Все данные хранятся в бинарном виде, и брокер мало знает про то, что они из себя представляют и какова их структура.

Каждый логический тип событий обычно находится в своей отдельном топике (topic). Например, событие создания объявления может попадать в топик item.created, а событие его изменения — в item.changed. Топики можно рассматривать как классификаторы событий. На уровне топика можно задать такие конфигурационные параметры, как:

• объём хранимых данных и/или их возраст (retention.bytes, retention.ms);
• фактор избыточности данных (replication factor);
• максимальный размер одного сообщения (max.message.bytes);
• минимальное число согласованных реплик, при котором в топик можно будет записать данные (min.insync.replicas);
• возможность провести failover на несинхронную отстающую реплику с потенциальной потерей данных (unclean.leader.election.enable);
• и ещё много других в соответствующем разделе документации Kafka.

В свою очередь, каждый топик разбивается на одну и более партицию (partition). Именно в партиции в итоге попадают события. Если в кластере более одного брокера, то партиции будут распределены по всем брокерам равномерно (насколько это возможно), что позволит масштабировать нагрузку на запись и чтение в один топик сразу на несколько брокеров.

На диске данные для каждой партиции хранятся в виде файлов сегментов, по умолчанию равных одному гигабайту (контролируется через log.segment.bytes). Важная особенность — удаление данных из партиций (при срабатывании retention) происходит как раз сегментами (нельзя удалить одно событие из партиции, можно удалить только целый сегмент, причём только неактивный).

Zookeeper — элемент выполняет роль хранилища метаданных и координатора. Именно он способен сказать:

• живы ли брокеры — посмотреть на это глазами zookeeper можно через zookeeper-shell командой ls /brokers/ids ;
• какой из брокеров является контроллером — get /controller ;
• находятся ли партиции в синхронном состоянии со своими репликами — get /brokers/topics/topic_name/partitions/partition_number/state .

Также именно к zookeeper сперва пойдут producer и consumer, чтобы узнать, на каком брокере какие топики и партиции хранятся. В случаях, когда для топика задан replication factor больше 1, zookeeper укажет, какие партиции являются лидерами — в них будет производиться запись и из них же будет идти чтение. В случае падения брокера именно в zookeeper будет записана информация о новых лидер-партициях

Producer — это чаще всего сервис, осуществляющий непосредственную запись данных в Apache Kafka. Producer выбирает topic, в котором будут храниться его тематические сообщения, и начинает записывать в него информацию. Например, producer’ом может быть сервис объявлений. В таком случае он будет отправлять в тематические топики такие события, как «объявление создано», «объявление обновлено», «объявление удалено» и так далее. Каждое событие при этом представляет собой пару «ключ-значение».

По умолчанию все события распределяются по партициям топика round-robin`ом, если ключ не задан (теряя упорядоченность), и через MurmurHash (ключ), если ключ присутствует (организуется упорядоченность в рамках одной партиции).

Kafka гарантирует порядок событий только в рамках одной партиции. Но на самом деле часто это не является проблемой. Например, можно гарантированно добавлять все изменения одного и того же объявления в одну партицию, сохраняя порядок этих изменений в рамках объявления. Также можно передавать порядковый номер в одном из полей события.

Consumer отвечает за получение данных из Apache Kafka. Если вернуться к примеру выше, consumer’ом может быть сервис модерации. Этот сервис будет подписан на топик сервиса объявлений. При появлении нового объявления будет получать его и анализировать на соответствие некоторым заданным политикам.Например, настроили на экономические новости, то вам придут только экономические новости, но не новости про спорт. Apache Kafka запоминает, какие последние события получил consumer для этого используется служебный топик __consumer__offsets. Тем самым гарантируя, что при успешном чтении consumer не получит одно и то же сообщение дважды, что иногда критически важно.

Итак, коротко об особенностях Apache Kafka:

• Главным сценарием применения транзакций в Apache Kafka является упомянутый выше сценарий «чтение-обработка-написание». В транзакции могут участвовать сразу несколько топиков и разделов. Отправитель начинает транзакцию, создаёт пакет сообщений, завершает транзакцию. Если получатели используют по умолчанию изоляционный уровень «читать незафиксированное», они видят все сообщения, независимо от их транзакционного статуса (завершена, не завершена, отменена). Если получатели используют изоляционный уровень «чтение зафиксированного», они не видят сообщения, транзакции которых не завершены или отменены. Они могут принимать сообщения только завершённых транзакций.
• Apache Kafka славится способностью поглощать и пересылать титанические объёмы данных. В нём есть всё, что нужно для работы с высокими нагрузками: репликация, горизонтальное масштабирование, параллельная обработка потоков сообщений сразу на нескольких серверах.
• Для защиты от сбоёв у Kafka предусмотрена архитектура «ведущий—ведомый» на уровне раздела журнала, и в этой архитектуре ведущие называются лидерами, а ведомые ещё могут называться репликами. Лидер каждого сегмента может иметь несколько ведомых. Если на сервере, где находится лидер, происходит сбой, предполагается, что реплика становится лидером и все сообщения сохраняются, только обслуживание на короткое время прерывается.
• Уведомления о получении сообщений и отслеживание смещения. Учитывая то, как Apache Kafka хранит сообщения, и то, как они доставляются получателям, Kafka полагается на уведомления о получении сообщений для источников и отслеживание смещения чтения топика для получателей.
• Когда источник посылает сообщение, он даёт знать брокеру Kafka, какого рода уведомление он хочет получить.
• У Apache Kafka предусмотрена хорошая опция против проблем с дублированием.
• Параллелизм и распределённая архитектура хорошо сказываются на надёжности: даже выход из строя части кластера не нарушит доставку сообщений.
• В пересылке данных принимают участие поставщики и потребители данных. Поставщики пишут сообщения в Apache Kafka, потребители их читают. Для организации систем со сложной топологией применяют темы — своего рода разделы для категоризации различных сообщений по назначению.
• Для маршрутизации сообщений могут применяться Routing Keys, похожие на те, что используются в RabbitMQ. Но, в отличие от RabbitMQ, Apache Kafka гарантирует порядок доставки сообщений. Apache Kafka придерживается концепции синхронизации реплик (In Sync Replicas, ISR). Каждая реплика может быть или не быть в синхронизированном состоянии. В первом случае она получает те же сообщения, что и лидер, за короткий отрезок времени (обычно за последние 10 секунд). Она выпадает из синхронизации, если не успевает эти сообщения принять. Такое может произойти из-за сетевой задержки, проблем с виртуальной машиной узла и т.д. Потеря сообщений может произойти только в случае сбоя лидера и отсутствия участвующих в синхронизации реплик.

Who is Mr. RabbitMQ

RabbitMQ — это распределённый и горизонтально масштабируемый брокер сообщений. Он позволяет разным программам взаимодействовать с помощью протокола AMQP, а через дополнительные модули и с помощью некоторых других протоколов: MQTT, HTTP и так далее.

Устройство брокера упрощённо можно описать так:

• есть продюсер или поставщик сообщений, отправляющий события;
• очередь сообщений — своего рода «‎почтовый ящик», где хранятся сообщения;
• подписчики, то есть программы — получатели сообщений.

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

RabbitMQ поддерживает несколько языков программирования — Perl, Python, Ruby, PHP. А также обеспечивает горизонтальное масштабирование для построения кластерных решений. Поэтому RabbitMQ часто применяется в различных сложных корпоративных проектах. Однако, в связи с некоторыми его технологическими особенностями реализации, не является полноценной заменой Apache Kafka.

В упрощённом виде управление сообщениями выполняется в RabbitMQ следующим образом:

• отправители (publishers) отправляют сообщения на обменники (exchange);
• обменники отправляют сообщения в очереди и в другие обменники;
• при получении сообщения RabbitMQ отправляет подтверждения отправителям;
• получатели (consumers) поддерживают постоянные TCP-соединения с RabbitMQ и объявляют, какую очередь они получают;
• RabbitMQ проталкивает (push) сообщения получателям;
• получатели отправляют подтверждения успеха или ошибки получения сообщения;
• после успешного получения сообщение удаляется из очереди.

Принцип работы RabbitMQ

RabbitMQ принимает сообщения от поставщиков и отправляет им подтверждение о приёме, а затем перенаправляет их подписчикам. Получатели подтверждают, что сообщение доставлено, либо сигнализируют о неудаче. Во втором случае сообщение остаётся в очереди, пока не будет доставлено. А после доставки оно удалится из системы.

Основная фишка RabbitMQ — это гибкая маршрутизация сообщений между различными поставщиками и потребителями событий. Решение не ограничивается созданием простой очереди данных между двумя сторонами. В сервере реализована концепция принимающих события узлов (эксчейнджей) — они маршрутизируют данные в разные очереди сообщений RabbitMQ.

Например, одно и то же сообщение должны получить три подписчика. Оно попадёт на узел, который отправит три одинаковых сообщения в три очереди для всех подписчиков, которым оно должно быть доставлено.

Визуализация маршрутизации RabbitMQ данных в разные очереди сообщений

Механизм маршрутизации дополняют ключи маршрутизации (Routing Keys). Они позволяют создавать гибкие правила пересылки сообщений между источниками и потребителями. Благодаря этому RabbitMQ подходит для широкого спектра задач по реализации нетривиальных бизнес-процессов в коде.

Коротко об особенностях RabbitMQ:

• Обширные инструменты маршрутизации позволяют разработчикам и администраторам настраивать сложные системы с тысячами источников и приёмников сообщений. Решение подходит для систем бронирования билетов, логистических программ и микросервисных приложений.
• RabbitMQ реализует концепцию push-доставки: поставщик может направить новые события в сеть, но получатель не может их запросить у поставщика. При этом система не гарантирует порядок доставки сообщений.

Чем отличаются Apache Kafka и RabbitMQ

Основные отличия Apache Kafka и RabbitMQ обусловлены принципиально разными моделями доставки сообщений, реализуемыми в этих системах. В частности, Apache Kafka действует по принципу вытягивания (pull), когда получатели (consumers) сами достают из топика (topic) нужные им сообщения. RabbitMQ, напротив, реализует модель проталкивания, отправляя необходимые сообщения получателям. В связи с этим Apache Kafka отличается от RabbitMQ по следующим критериям:

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

Сохранение сообщений — RabbitMQ помещает сообщение в очередь FIFO (First Input — First Output) и отслеживает статус этого сообщения в очереди, а Apache Kafka добавляет сообщение в журнал (записывает на диск), предоставляя получателю самому заботиться о получении нужной информации из топика. RabbitMQ удаляет сообщение после доставки его получателю, а Kafka хранит сообщение до тех пор, пока не наступит момент запланированной очистки журнала. Таким образом, Apache Kafka сохраняет текущее и все прежние состояния системы и может использоваться в качестве достоверного источника исторических данных, в отличие от RabbitMQ.

Балансировка — благодаря pull-модели доставки сообщений RabbitMQ сокращает время задержки. Однако возможно переполнение получателей, если сообщения прибудут в очередь быстрее, чем те могут их обработать. Поскольку в RabbitMQ каждый получатель запрашивает/выгружает разное количество сообщений, то распределение работы может стать неравномерным, что повлечёт задержки и потерю порядка сообщений во время обработки. Для предупреждения этого каждый получатель RabbitMQ настраивает предел предварительной выборки — ограничение на количество скопившихся неподтверждённых сообщений. В Apache Kafka балансировка нагрузки выполняется автоматически путём перераспределения получателей по разделам (partition) топика.

Пропускная способность — Kafka гарантирует порядок сообщений в разделе топика (partition) без конкурирующих получателей, что позволяет объединять сообщения в пакеты для более эффективной доставки и повышает пропускную способность системы.

Масштабируемость — Apache Kafka считается более адаптивной к масштабированию, обеспечивая ежедневный обмен миллиардами сообщений. Однако далеко на каждый проект с Big Data нуждается в таких высоких цифрах.

Маршрутизация — RabbitMQ включает четыре способа маршрутизации на разные обменники (exchange) для постановки в различные очереди, что позволяет использовать мощный и гибкий набор шаблонов обменов сообщениями. Kafka реализует лишь один способ записи сообщений на диск, без маршрутизации.

Упорядочивание сообщений — RabbitMQ позволяет поддерживать относительный порядок в произвольных наборах (группах) событий, а Apache Kafka обеспечивает простой способ поддержания упорядочения с поддержкой масштабирования путём последовательной записи сообщений в реплицированный журнал (топик).

Работа с клиентом — про Apache Kafka говорят «тупой сервер, умный клиент», что означает необходимость реализации логики работы с сообщениями на клиентской стороне, т.е. consumer заботится о получении нужных сообщений. RabbitMQ — наоборот, «умный сервер, тупой клиент», поскольку этот брокер сам обеспечивает всю логику работы с сообщениями.

Так что выбрать?

Обратной стороной широких и разнообразных возможностей RabbitMQ по гибкому управлению очередями сообщений (маршрутизация, шаблоны доставки, мониторинг получения) является повышенное потребление ресурсов и, соответственно, снижение производительности в условиях увеличенных нагрузок. Поскольку именно такой режим работы характерен для сложных систем, то в большинстве случаев Apache Kafka является наилучшим средством для управления сообщениями.

Например, в случае сбора и агрегации множества событий от десятков систем, и сервисов с учётом их георезервирования, клиентских метрик, лог-файлов и аналитики с перспективой увеличения источников информации понадобится Apache Kafka. А если необходим быстрый обмен сообщениями между несколькими сервисами, RabbitMQ отлично справится с этой задачей.

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

В целом RabbitMQ предоставляет надёжные, долговременные гарантии обмена сообщениями, но есть очень много ситуаций, когда они не помогут. Вот список моментов, которые следует запомнить:

• Следует применять зеркалирование очередей, надёжные очереди, устойчивые сообщения, подтверждения для отправителя, флаг подтверждения и принудительное уведомление от получателя, если требуются надёжные гарантии в стратегии «как минимум однократная доставка».
• Если отправка производится в рамках стратегии «как минимум однократная доставка», может потребоваться добавить механизм дедубликации или идемпотентности при дублировании отправляемых данных.
• Если вместе с RabbitMQ используется устаревший API для считывания больших пакетов, это может привести к крайне неравномерной нагрузке между конфликтующими между собой получателями и значительным задержкам в обработке данных. RabbitMQ по своему устройству не подходит для пакетной обработки сообщений.
• Если вопрос потери сообщений не так важен, как вопрос скорости доставки и высокой масштабируемости, то подумайте о системах без резервирования, без устойчивых сообщений и без подтверждений на стороне источника. Проще говоря, RabbitMQ не подходит для финансового сектора.

Выбирайте RabbitMQ, если вам нужна гибкость маршрутизации, а порядок доставки сообщений безразличен, что, к сожалению, не подходит для финансового сектора. Apache Kafka, в свою очередь, подойдёт идеально, если работаете с большими нагрузками (mission and business critical системы), важна масштабируемость, доставка сообщений в правильном порядке и возможность просматривать историю сообщений.

В чем разница между Kafka и RabbitMQ?

Kafka и RabbitMQ — это системы очередей сообщений, которые можно использовать при потоковой обработке. Поток данных — это непрерывные инкрементные данные большого объема, требующие высокоскоростной обработки. Например, это могут быть данные датчиков об окружающей среде, которые необходимо постоянно собирать и обрабатывать для наблюдения за изменениями температуры или давления воздуха в реальном времени. RabbitMQ — это брокер распределенных сообщений, который собирает потоковые данные из нескольких источников и маршрутизирует их в разные пункты назначения для обработки. Apache Kafka — это платформа потоковой трансляции для создания конвейеров данных и приложений потоковой трансляции в реальном времени. Kafka предоставляет высокомасштабируемую, отказоустойчивую и надежную систему обмена сообщениями с большими возможностями, чем RabbitMQ.

Архитектурные различия Kafka и RabbitMQ

RabbitMQ и Apache Kafka позволяют производителям отправлять сообщения потребителям. Производители — это приложения, публикующие информацию, а потребители — приложения, которые подписываются на информацию и обрабатывают ее.

В RabbitMQ и Kafka производители и потребители взаимодействуют по-разному. В RabbitMQ производитель отправляет сообщение и отслеживает, дошло ли оно до предполагаемого потребителя. С другой стороны, производители Kafka публикуют сообщения в очереди независимо от того, получили ли их потребители.

RabbitMQ можно рассматривать как почтовое отделение, которое принимает почту и доставляет ее предполагаемым получателям. Между тем Kafka похож на библиотеку, где на полках раскладываются сообщения разных жанров, публикуемые производителями. Затем потребители читают сообщения с соответствующих полок и запоминают прочитанное.

Архитектурный подход RabbitMQ

Брокер RabbitMQ обеспечивает низкую задержку и сложное распределение сообщений с помощью следующих компонентов:

• Биржа получает сообщения от производителя и определяет, куда их следует направлять.
• Очередь — это хранилище, которое получает сообщения от биржи и отправляет их потребителям.
• Привязка — это путь, соединяющий биржу и брокера.

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

Архитектурный подход Kafka

Кластер Kafka обеспечивает обработку потоковых событий с более сложной архитектурой с высокой пропускной способностью. Вот несколько ключевых компонентов Kafka:

• Брокер Kafka — это сервер Kafka, который позволяет производителям передавать потоки данных потребителям. Брокер Kafka содержит темы и соответствующие разделы.
• Тема — носитель данных, в котором сгруппированы похожие данные в брокере Kafka.
• Раздел — это небольшой носитель данных в теме, на которую подписаны потребители.
• ZooKeeper — это специальное программное обеспечение, которое управляет кластерами и разделами Kafka для обеспечения отказоустойчивой потоковой передачи. ZooKeeper недавно было заменено протоколом Apache Kafka Raft (KRaft).

Производители в Kafka назначают каждому сообщению ключ сообщения. Затем брокер Kafka сохраняет сообщение в ведущем разделе этой конкретной темы. Протокол KRaft использует алгоритмы консенсуса для определения ведущего раздела.

Как Kafka и RabbitMQ по-разному обрабатывают сообщения?

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

RabbitMQ и Kafka предназначены для разных примеров использования, поэтому они по-разному обрабатывают обмен сообщениями. Далее мы обсудим некоторые конкретные различия.

Потребление сообщений

В RabbitMQ брокер гарантирует получение сообщения потребителями. Потребительское приложение играет пассивную роль и ждет, пока брокер RabbitMQ отправит сообщение в очередь. Например, банковское приложение может ждать SMS-предупреждение от программного обеспечения для централизованной обработки транзакций.

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

Приоритет сообщения

Брокеры RabbitMQ позволяют программному обеспечению производителя увеличивать количество определенных сообщений, используя очередь приоритетов. Вместо отправки сообщений в порядке «первым пришел — первым ушел» брокер обрабатывает сообщения с более высоким приоритетом, чем обычные сообщения. Например, приложение для розничной торговли может ставить транзакции в очередь каждый час. Однако если системный администратор отправляет приоритетное сообщение резервного копирования базы данных, то брокер немедленно отправляет его.

В отличие от RabbitMQ, Apache Kafka не поддерживает приоритетные очереди. При распределении по соответствующим разделам все сообщения рассматриваются как равные.

Порядок сообщений

RabbitMQ отправляет сообщения и ставит их в очередь в определенном порядке. Если сообщение с более высоким приоритетом не поставлено в очередь в систему, потребители получают сообщения в том порядке, в котором они были отправлены.

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

Удаление сообщения

Брокер RabbitMQ маршрутизирует сообщение в очередь назначения. После прочтения потребитель отправляет брокеру ответ с подтверждением (ACK), который затем удаляет сообщение из очереди.

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

Другие ключевые отличия Kafka от RabbitMQ

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

Далее мы расскажем о других различиях между обоими брокерами сообщений.

Производительность

И RabbitMQ, и Kafka предлагают высокопроизводительную передачу сообщений для предполагаемых примеров использования. Однако Kafka превосходит RabbitMQ по пропускной способности сообщений.

Kafka может отправлять миллионы сообщений в секунду, поскольку использует последовательный дисковый ввод-вывод для обеспечения высокой пропускной способности обмена сообщениями. Последовательный дисковый ввод-вывод — это система хранения данных, которая хранит данные из смежного пространства памяти и получает к ним доступ быстрее, чем произвольный доступ к диску.

RabbitMQ также может отправлять миллионы сообщений в секунду, но для этого требуется несколько брокеров. Обычно производительность RabbitMQ составляет в среднем тысячи сообщений в секунду и может замедлиться, если очереди RabbitMQ перегружены.

Безопасность

RabbitMQ и Kafka позволяют приложениям безопасно обмениваться сообщениями, но с использованием разных технологий.

RabbitMQ поставляется с инструментами администрирования для управления разрешениями пользователей и безопасностью брокеров.

Между тем архитектура Apache Kafka обеспечивает безопасные потоки событий с помощью TLS и службы аутентификации и авторизации Java (JAAS). TLS — это технология шифрования, предотвращающая непреднамеренное прослушивание сообщений, а JAAS контролирует, какое приложение имеет доступ к брокерской системе.

Язык программирования и протоколы

И Kafka, и RabbitMQ поддерживают различные языки, платформы и протоколы, знакомые разработчикам.

Вы можете писать код на Java и Ruby при создании клиентских приложений для Kafka и RabbitMQ. Кроме того, Kafka поддерживает Python и Node.js, а RabbitMQ поддерживает JavaScript, Go, C, Swift, Spring, Elixir, PHP и .NET.

Kafka использует протокол передачи двоичных данных через TCP для потоковой передачи сообщений по конвейерам данных в реальном времени, а RabbitMQ по умолчанию поддерживает протокол расширенной очереди сообщений (AMQP). RabbitMQ также поддерживает устаревшие протоколы, такие как простой потоковый текст-ориентированный протокол обмена сообщениями (STOMP) и MQTT, для маршрутизации сообщений.

В чем сходство между Kafka и RabbitMQ?

Для обмена данными в облаке приложениям нужны надежные брокеры сообщений. И RabbitMQ, и Kafka предоставляют масштабируемые и отказоустойчивые платформы для удовлетворения растущих требований к трафику и высокой доступности.

Далее мы обсудим некоторые ключевые сходства между RabbitMQ и Kafka.

Масштабируемость

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

Кроме того, архитектура Kafka позволяет добавлять больше разделов к определенной теме для равномерного распределения нагрузки сообщений.

Отказоустойчивость

И Kafka, и RabbitMQ представляют собой надежные архитектуры очередей сообщений, устойчивые к сбоям системы.

Можно сгруппировать несколько брокеров RabbitMQ в кластеры и развернуть их на разных серверах. RabbitMQ также реплицирует сообщения в очереди между распределенными узлами. Это позволяет системе восстанавливаться после сбоя, затрагивающего любой сервер.

Как и RabbitMQ, Apache Kafka обладает аналогичными возможностями восстановления и резервирования благодаря хостингу кластеров Kafka на разных серверах. Каждый кластер состоит из реплик файлов журналов, которые можно восстановить в случае сбоя.

Простота использования

Обе системы очередей сообщений имеют мощную поддержку сообщества и библиотеки, упрощающие отправку, чтение и обработку сообщений. Это упрощает разработку клиентских приложений для разработчиков обеих систем.

Например, вы можете использовать Kafka Streams (клиентскую библиотеку) для создания систем обмена сообщениями на Kafka, а Spring Cloud Data Flow — для создания управляемых событиями микросервисов с помощью RabbitMQ.

Когда использовать Kafka, а когда RabbitMQ

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

Далее мы обсудим некоторые примеры использования RabbitMQ и Kafka, достойные рассмотрения.

Воспроизведение потоков событий

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

Агрегировать журналы с помощью RabbitMQ сложнее, поскольку сообщения удаляются сразу после использования. Обходной путь — воспроизвести сохраненные сообщения от производителей.

Обработка данных в реальном времени

Kafka передает сообщения с очень низкой задержкой и подходит для анализа потоковых данных в реальном времени. Например, вы можете использовать Kafka в качестве распределенной службы мониторинга для отправки предупреждений об обработке онлайн-транзакций в реальном времени.

Сложная архитектура маршрутизации

RabbitMQ обеспечивает гибкость для клиентов с приблизительными требованиями или сложными сценариями маршрутизации. Например, вы можете настроить RabbitMQ для маршрутизации данных в разные приложения с разными привязками и обменами.

Эффективная доставка сообщений

RabbitMQ применяет модель push, что означает, что производитель знает, использовало ли клиентское приложение сообщение. Этот вариант подходит для приложений, которые должны соблюдать определенные последовательности и предоставлять гарантии доставки при обмене данными и их анализе.

Поддержка языков и протоколов

Разработчики используют RabbitMQ для приложений клиентов, требующих обратной совместимости с устаревшими протоколами, такими как MQTT и STOMP. RabbitMQ также поддерживает более широкий спектр языков программирования по сравнению с Kafka.

Использует ли Kafka RabbitMQ?

Kafka не использует RabbitMQ. Это независимый брокер сообщений, который распространяет потоки событий в реальном времени без использования RabbitMQ. Оба брокера являются отдельными системами обмена данными, которые работают независимо друг от друга.

Однако некоторые разработчики направляют сообщения из сети RabbitMQ в Kafka. Они делают это потому, что для разборки существующих конвейеров данных RabbitMQ и их перестроения с помощью Kafka требуется больше усилий.

Краткое описание различий: Kafka и RabbitMQ

Архитектура RabbitMQ разработана для сложной маршрутизации сообщений. В ней используется модель push. Производители отправляют сообщения потребителям с другими правилами.

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

Брокеры RabbitMQ отслеживают потребление сообщений. Сообщения удаляются после их потребления. RabbitMQ поддерживает приоритеты сообщений.

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

RabbitMQ имеет низкую задержку. Он отправляет тысячи сообщений в секунду.

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

Язык программирования и протокол

RabbitMQ поддерживает широкий спектр языков и устаревших протоколов.

Выбор языков программирования Kafka ограничен. Он использует протокол передачи двоичных данных через TCP для передачи данных.

Как AWS может поддерживать выполнение требований RabbitMQ и Kafka?

Amazon Web Services (AWS) предоставляет полностью управляемые сервисы брокера сообщений с низкой задержкой для реализаций RabbitMQ и Kafka.

• Используйте Amazon MQ для предоставления услуг брокерам RabbitMQ без трудоемких настроек. Amazon MQ шифрует сообщения RabbitMQ при передаче и хранении. Мы также обеспечиваем конвейеры данных высокой доступности в зонах доступности AWS.

• Используйте управляемую потоковую передачу Amazon для Apache Kafka (Amazon MSK) для простой настройки, обработки и масштабирования шины сообщений Kafka в реальном времени. Amazon MSK помогает создавать отказоустойчивые и безопасные потоки событий с помощью технологий AWS, таких как виртуальное частное облако Amazon (Amazon VPC).

Создайте аккаунт уже сегодня и начните работу с брокерами сообщений на AWS.

Сравниваем эффективность Redis, Kafka и RabbitMQ

Чтобы обеспечить асинхронную связь между микросервисами (microservices), нужен брокер сообщений (message broker). Брокер обеспечивает надежную и стабильную передачу данных, управление и мониторинг, а также предотвращает потерю сообщений. На сегодняшний день существует несколько брокеров, которые различаются по возможностям и объемам передаваемых данных. Сравним три наиболее популярных из них — RabbitMQ, Kafka и Redis.

Синхронная и асинхронная связь между микросервисами

Чтобы обеспечить взаимодействие между микросервисами, используют два распространенных способа: синхронный и асинхронный. В первом случае вызывающая сторона ожидает ответа перед отправкой сообщения, работая как протокол REST (Representational state transfer) поверх HTTP. Во втором — сообщения отправляются, не ожидая ответа. Такой вариант подходит для распределенных систем и обычно нуждается в брокере для управления сообщениями.

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

Преимущества асинхронной связи

1. Асинхронная связь по определению не блокируемая.
2. Она поддерживает лучшее масштабирование, чем при синхронном режиме.
3. В случае сбоев в работе микросервисов механизмы асинхронной связи предоставляют различные методы восстановления данных и, как правило, лучше справляются с подобными ошибками.

Кроме того, при использовании брокеров сообщений вместо протокола REST, участвующим в обмене данными сервисам не нужно знать друг о друге. Новый сервис можно добавить к уже давно работающему, т. е. они более “развязаны”.

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

Критерии выбора брокера сообщений

Асинхронная передача данных обычно выполняется через брокера сообщений. Другие способы, такие как AsyncIO, имеют ограниченные возможности.

При выборе брокера асинхронного режима следует учитывать ряд требований.

1. Scale (масштаб брокера) — количество сообщений, отправляемых в системе, в секунду.
2. Data Persistency (постоянное хранение данных, персистентность) — возможность восстановления сообщений.
3. Клиентские возможности — способность управлять клиентами в режиме one-to-one (один к одному) и/или one-to-many (один ко многим).

Теперь оценим лучшие современные сервисы, чтобы выбрать наиболее эффективного провайдера по этим трем критериям.

Сравнение брокеров сообщений

RabbitMQ (AMQP)

• Scale. Зависит от конфигурации и ресурсов, приблизительно около 50 тысяч сообщений в секунду.
• Persistency. Поддерживаются как постоянные, так и временные сообщения.
• One-to-one и one-to-many. Поддерживаются оба режима.

RabbitMQ — один из первых брокеров общих сообщений, выпущенный в 2007 году. Это приложение с открытым исходным кодом реализует расширенные протоколы очереди сообщений (AMQP). Сообщения доставляются и методом point-to-point, и методом pub-sub. Поддерживается сложная логика маршрутизации.

Есть несколько управляемых сервисов, которые позволяют использовать RabbitMQ как SaaS, но он не входит в стек крупных облачных провайдеров. RabbitMQ поддерживается всеми основными языками, включая Python, Java, .NET, PHP, Ruby, JavaScript, Go, Swift и другие.

При высокой нагрузке возможны некоторые проблемы с производительностью.

Kafka

• Scale. До 1 млн сообщений в секунду.
• Persistency. Доступно.
• One-to-one и one-to-many. Поддерживается только one-to-many.

Kafka был разработан Linkedin в 2011 году для обработки данных при высокой пропускной способности и с малой задержкой. Распределенная потоковая платформа Kafka имитирует сервис публикации и подписки (publish-subscribe service). Она обеспечивает постоянное хранение данных и потоков записей, что позволяет обмениваться качественными сообщениями.

Kafka доступна как SaaS на Azure, AWS и Confluent, которые являются создателями и основными участниками этого проекта. Kafka поддерживается всеми основными языками, включая Python, Java, C/C++, Clojure, .NET, PHP, Ruby, JavaScript, Go, Swift и другие.

Redis

• Scale. До 1 млн сообщений в секунду.
• Persistency. Встроенная память для хранения данных отсутствует.
• One-to-one и one-to-many. Поддерживаются оба режима.

Redis немного отличается от других брокеров сообщений. Он предоставляет высокопроизводительное хранилище данных в памяти, которое можно использовать для хранения ключей, либо как брокер сообщений. Еще одна особенность заключается в том, что Redis не обладает персистентностью (механизм постоянного хранения данных), а наоборот сбрасывает данные на диск/в базу данных. Этот брокер идеально подходит для обработки данных в режиме реального времени.

Изначально Redis не поддерживал режимы one-to-one и one-to-many. Однако в версии Redis 5.0 после расширения возможностей pub-sub появился one-to-many.

Варианты использования брокеров сообщений

Сравним еще раз возможности RabbitMQ, Kafka и Redis. Все три брокера успешно выполняют свои задачи, но действуют при этом совершенно по-разному. Вот рекомендации по выбору в соответствии с особенностями использования.

Сообщения с коротким жизненным циклом — Redis

Резидентная (in-memory) база данных Redis почти идеально подходит для обмена кратковременными сообщениями, когда не требуется персистентность. Благодаря чрезвычайно быстрому обслуживанию и резидентной памяти Redis идеально подходит для обмена сообщениями с незначительной задержкой, когда персистентность не так важна и можно допустить некоторые потери. С версии 5.0 появилась поддержка режима one-to-many, что было необходимо из-за ограниченных ранее возможностей pub-sub.

Большие объемы данных — Kafka

Kafka — это распределенная очередь с высокой пропускной способностью, созданная для длительного хранения больших объемов данных. Она идеально подходит в тех случаях, где требуется персистентность.

Сложная маршрутизация — RabbitMQ

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

И финальный этап

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

Например, если в системе есть Celery для Task Queue поверх RabbitMQ, удобнее работать с RabbitMQ или Redis, а не с Kafka, который не поддерживается и потребует написания дополнительного кода.

Чтобы выбрать необходимый инструмент, важно понимать все их плюсы и минусы, с учетом конкретного применения, ситуации и требований.

• Рабочая очередь в Go с RabbitMQ
• Как сделать сайт в 25 раз быстрее с помощью нескольких строк кода
• ClickHouse + Kafka = ❤