Есть ли причина использовать RabbitMQ над Kafka?

Ответ 1

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

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

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

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

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

Дополнительную информацию по чтению и сравнению можно найти здесь: https://www.cloudkarafka.com/blog/2016-12-05-apachekafka-vs-rabbitmq.html

Также рекомендуем отраслевой документ: "Кафка против RabbitMQ: сравнительное исследование двух отраслевых реализаций публикации/подписки": http://dl.acm.org/citation.cfm?id=3093908

Я работаю в компании, которая предоставляет Apache Kafka и RabbitMQ в качестве Сервиса.

Ответ 2

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

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

Статья " Apache Kafka против Enterprise Service Bus (ESB) - друзья, враги или заклятые враги?" (Https://www.confluent.io/blog/apache-kafka-vs-enterprise-service-bus-esb-friends- враги-или-заклятые люди /) "обсуждает, почему Kafka не конкурентоспособен, а дополняет решения по интеграции и обмену сообщениями (включая RabbitMQ) и как интегрировать оба.

Ответ 3

5 Основные различия между Kafka и RabbitMQ, клиентами, которые их используют:

Какую систему обмена сообщениями выбрать, или мы должны изменить нашу существующую систему обмена сообщениями?

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

Ответ 4

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

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

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

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

Архитектура становится сложной, поскольку для обеспечения возможности взаимодействия этих услуг требуются различные интеграции. Точнее говоря, для архитектуры, которая включает в себя m исходных и n целевых служб, необходимо написать n x m различных интеграций. Кроме того, каждая интеграция поставляется с другой спецификацией, что означает, что для нее может потребоваться другой протокол (HTTP, TCP, JDBC и т.д.) Или другое представление данных (Binary, Apache Avro, JSON и т.д.), Что еще более усложняет задачу., Кроме того, исходные службы могут справляться с повышенной нагрузкой на соединения, что может повлиять на задержку.

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

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

Решение о том, пойти ли вам на RabbitMQ или Kafka, зависит от требований вашего проекта. В общем, если вам нужен простой/традиционный брокер сообщений pub-sub, тогда выбирайте RabbitMQ. Если вы хотите построить управляемую событиями архитектуру, поверх которой ваша организация будет воздействовать на события в режиме реального времени, тогда выберите Apache Kafka, поскольку он предоставляет больше функциональных возможностей для этого типа архитектуры (например, Kafka Streams и/или KSQL).,

Ответ 5

Ребята, вы забыли одно важное отличие - RabbitMQ - это система обмена сообщениями на основе push, тогда как Kafka - это система обмена сообщениями на основе pull. Это важно в сценарии, где система обмена сообщениями должна удовлетворять разным типам потребителей с различными возможностями обработки. С системой на основе Pull потребитель может потреблять в зависимости от своих возможностей, тогда как системы push-уведомлений будут отправлять сообщения независимо от состояния потребителя, тем самым подвергая потребителя высокому риску.

Ответ 6

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

RabbitMQ: Я бы выбрал этот вариант, если бы мои требования были достаточно просты для взаимодействия с системой через каналы/очереди, сохранение и потоковая передача не являются обязательными. Например, когда система производства создала актив, она уведомляет систему соглашения о настройке контрактов и так далее.

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

Ответ 7

Единственное преимущество, которое я могу придумать, - это транзакционная функция, а все остальное можно сделать с помощью Kafka.

Ответ 8

Я знаю это немного поздно, и, может быть, вы уже, косвенно, сказали это, но опять же, Кафка вовсе не очередь, это журнал (как кто-то сказал выше, основанный на опросе).

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

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

Максимум, что вы могли бы сделать, это сделать, как эти парни, и попытаться преобразовать Кафку в очередь: https://github.com/softwaremill/kmq

Янник

Ответ 9

Используйте RabbitMQ, когда:

• Вам не нужно работать с Bigdata, и вы предпочитаете удобный встроенный пользовательский интерфейс для мониторинга
• Нет необходимости автоматически реплицируемых очередей
• Нет нескольких подписчиков для messages-, поскольку в отличие от Kafka, который является журналом, RabbitMQ является очередью, и сообщения удаляются после использования и получения подтверждения
• Если у вас есть требования для использования подстановочных знаков и регулярных выражений для сообщений
• Если важно определить приоритет сообщения

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

Ответ 10

Масштабировать оба сложно распределенным отказоустойчивым способом, но я бы сказал, что с RabbitMQ это гораздо сложнее в массовом масштабе. Нетрудно понять Shovel, Federation, Mirrored Msg Queues, ACK, Mem, Tollelerance и т.д. Не говоря уже о том, что у вас не будет особых проблем с Zookeeper и т.д. На Kafka, но есть меньше движущихся частей, которыми нужно управлять. Тем не менее, вы получаете обмен Polyglot с RMQ, а с Kafka - нет. Если вы хотите потоковую передачу, используйте Kafka. Если вы хотите простой IoT или аналогичную доставку пакетов большого объема, используйте Kafka. Это про умных потребителей. Если вам нужна гибкость сообщений и более высокая надежность при более высоких затратах и, возможно, некоторой сложности, используйте RMQ.

Ответ 11

Сейчас это популярный вопрос о популярности Кафки. Я пробовал листинг 1. Основные различия между Kafka и RabbitMQ 2. Клиент/сценарий, в котором он используется, и 3. Какую систему обмена сообщениями выбрать или мы должны изменить нашу существующую систему обмена сообщениями? Блог: https://shishirkumarblog.wordpress. Система com/technical/kafka-vs-rabbitmq-amqp% e2% 80% 8b/ Youtube: https://youtu.be/hpBGvOSvWwg