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

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

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

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

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

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

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

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

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

Дополнительную информацию и некоторые сравнительные данные можно найти здесь: https://www.cloudamqp.com/blog/2019-12-12-when-to-use-rabbitmq-or-apache-kafka.html.

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

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

Я слышу этот вопрос каждую неделю ... Хотя 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-enemies-or-frenemies/ ) »обсуждает, почему Kafka не является конкурентоспособной, но дополняет решения по интеграции и обмену сообщениями (включая RabbitMQ) и как интегрировать оба.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Янник

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

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

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

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

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

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

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

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

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

Apache Kafka является популярным выбором для питания конвейеров данных. Apache kafka добавил поток kafka для поддержки популярных сценариев использования etl. KSQL упрощает преобразование данных в конвейере, готовя сообщения для чистого попадания в другую систему. KSQL - это движок SQL для Apache Kafka. Он предоставляет простой в использовании, но мощный интерактивный интерфейс SQL для потоковой обработки на Kafka, без необходимости писать код на языке программирования, таком как Java или Python. KSQL является масштабируемым, эластичным, отказоустойчивым и работает в режиме реального времени. Он поддерживает широкий спектр потоковых операций, включая фильтрацию данных, преобразования, агрегации, объединения, управление окнами и сеансами.

https://docs.confluent.io/current/ksql/docs/index.html

Rabbitmq не является популярным выбором для систем etl, скорее для тех систем, где он требует простых систем обмена сообщениями с меньшей пропускной способностью.

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

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

Хотя оба продукта могут быть сконфигурированы так, чтобы сохранять (или не сохранять) сообщения, если соблюдение требований CCPA или GDPR является проблемой, я бы остановился на RabbitMQ.

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

Я внедрил Kafka в наш продукт, где мы обрабатывали более 70 кбит / с транзакций, и задержка составляла в среднем 15 мс, а количество пиков достигало 40 мс. Размер темы был 100кб.

PFB больше точек данных о KAFKA и RabbitMQ: Apache Kafka включает в себя самого брокера, который на самом деле является самой известной и самой популярной его частью, и был разработан и широко представлен для сценариев потоковой обработки. В дополнение к этому, Apache Kafka недавно добавил Kafka Streams, который позиционирует себя как альтернативу потоковым платформам, таким как Apache Spark, Apache Flink, Apache Beam / Облачный поток данных Google и Spring Cloud Data Flow. Документация хорошо обсуждает популярные варианты использования, такие как отслеживание активности веб-сайтов, метрики, объединение журналов, обработка потоков, журналы событий и фиксация. Один из описанных вариантов использования - это обмен сообщениями, который может вызвать некоторую путаницу. Итак, давайте немного распакуем и выясним, какие сценарии обмена сообщениями лучше всего подходят для Kafka, например:

Поток от A до B без сложной маршрутизации, с максимальной пропускной способностью (100k / sec +), доставляется в секционированном порядке хотя бы один раз. Когда вашему приложению необходим доступ к истории потоков, доставленной в секционированном порядке хотя бы один раз. Kafka - это долговременное хранилище сообщений, и клиенты могут получать «воспроизведение» потока событий по требованию, в отличие от более традиционных посредников сообщений, когда после доставки сообщения оно удаляется из очереди. Потоковая обработка событий Event RabbitMQ - это решение для обмена сообщениями общего назначения, которое часто используется для того, чтобы веб-серверы могли быстро реагировать на запросы, вместо того чтобы заставлять выполнять ресурсоемкие процедуры, пока пользователь ожидает результата. Это также хорошо для рассылки сообщения нескольким получателям для потребления или для распределения нагрузки между работниками, находящимися под высокой нагрузкой (20k + / сек). Когда ваши требования выходят за пределы пропускной способности, RabbitMQ может предложить множество возможностей: надежную доставку, маршрутизацию, федерацию, HA, безопасность, инструменты управления и другие функции. Давайте рассмотрим некоторые сценарии, наиболее подходящие для RabbitMQ, например:

Ваше приложение должно работать с любой комбинацией существующих протоколов, таких как AMQP 0-9-1, STOMP, MQTT, AMQP 1.0. Вам необходим более детальный контроль / гарантии согласованности для каждого сообщения (очереди недоставленных писем и т. Д.). Однако Kafka недавно добавила улучшенную поддержку транзакций. Ваше приложение нуждается в разнообразии: точка-точка, запрос / ответ и публикация / подписка на сообщения. Сложная маршрутизация для потребителей, интеграция нескольких сервисов / приложений с нетривиальной логикой маршрутизации. RabbitMQ также может эффективно справляться с несколькими сильными случаями использования Kafka, описанными выше, но с помощь дополнительного программного обеспечения. RabbitMQ часто используется с Apache Cassandra, когда приложению требуется доступ к истории потоков, или с плагином LevelDB для приложений, которым требуется «бесконечная» очередь, но ни одна из функций не поставляется с самим RabbitMQ.

Краткий ответ - «подтверждение сообщения». RabbitMQ может быть настроен так, чтобы требовать подтверждения сообщения. Если получатель терпит неудачу, сообщение возвращается в очередь, и другой получатель может повторить попытку. Хотя вы можете сделать это в Kafka с помощью собственного кода, он работает с RabbitMQ из коробки.

По моему опыту, если у вас есть приложение, которое имеет требования для запроса потока информации, Kafka и KSql - ваш лучший выбор. Если вам нужна система очередей, вам лучше использовать RabbitMQ.

Ответ, получивший наибольшее количество голосов, охватывает большую часть, но я хотел бы высветить точку зрения варианта использования. Может ли kafka сделать то, что может сделать кролик mq, ответ - да, но может ли кролик сделать все, что делает kafka, ответ - нет. Итак, что не может сделать rabbit mq, который разделяет kafka, то есть распределенную обработку сообщений. Теперь прочитайте ответ с наибольшим количеством голосов, и это будет иметь больше смысла. В качестве примера рассмотрим случай, когда вам нужно создать систему обмена сообщениями с очень высокой пропускной способностью, например «лайки» в facebook, и вы выбрали для этого rabbit mq. Вы создали обмен, очередь и потребителя, где все издатели (в данном случае пользователи FB) могут публиковать сообщения «лайки». Так как ваша пропускная способность высока, Вы создадите несколько потоков в потребителе для параллельной обработки сообщений, но вы все равно будете ограничены аппаратными возможностями компьютера, на котором работает потребитель. Предполагая, что одного потребителя недостаточно для обработки всех сообщений - что бы вы сделали? Можете ли вы добавить еще одного потребителя в очередь - нет, вы не можете этого сделать. Можете ли вы создать новую очередь и привязать эту очередь к обмену, которая публикует сообщение «лайки», ответ - нет, потому что вы будете обрабатывать сообщения дважды. Это основная проблема, которую решает Кафка. Это позволяет вам создавать распределенные разделы (Queue in rabbit mq) и распределенного потребителя, которые общаются друг с другом. Это гарантирует, что ваши сообщения в теме будут обрабатываться потребителями, распределенными по различным узлам (машинам). Брокеры Kafka обеспечивают сбалансированную загрузку сообщений по всем разделам этой темы. Потребительская группа следит за тем, чтобы все потребители общались друг с другом, и сообщение не обрабатывалось дважды. Но в реальной жизни вы не столкнетесь с этой проблемой, если ваш проходной уровень не будет слишком высоким, потому что rabbit mq также может очень быстро обрабатывать данные даже с одним потребителем.