Message Queues & Brokers
Очереди и Брокеры
Очереди и Брокеры сообщений
Очереди
Общая информация
https://www.ibm.com/ru-ru/cloud/learn/message-brokers
What Is a Message Queue? | IBM
Система обмена сообщениями
Message oriented middleware - MOM
Процедура передачи сообщения:
Создание. Отправитель создает сообщение.
Отправка. Отправитель помещает сообщение в канал.
Доставка. Система обмена сообщениями доставляет сообщение с компьютера отправителя на компьютер получателя.
Получение. Получатель извлекает сообщение из канала.
Обработка. Получатель считывает полезную информацию.
2 концепции обмена сообщениями:
Отправить и забыть.
Передача с промежуточным хранением.
Брокеры сообщений
Брокер сообщений — это технология, обеспечивающая связь между приложениями и помогающая создать общий механизм интеграции для поддержки облачных, микросервисных, бессерверных и гибридных архитектур. Это делается посредством перевода сообщений из одного формального протокола обмена сообщениями в другой. Таким образом независимые службы могут «общаться» между собой напрямую, даже если они написаны на разных языках или реализованы на разных платформах.
Брокеры сообщений проверяют, хранят, маршрутизируют сообщения и доставляют их в место назначения. Они выступают в качестве брокеров между разными приложениями: для отправления сообщений отправителям не обязательно знать, где находятся получатели, активны ли они и сколько их всего. Это упрощает разделение процессов и услуг внутри систем.
Чтобы обеспечить надежное хранение сообщений (пакеты данных) и гарантированную доставку, в брокерах часто используется очередь сообщений — вспомогательная структура или компонент, который хранит и упорядочивает сообщения, пока они не будут обработаны приложениями-получателями. Сообщения в очереди хранятся в том же порядке, в котором они были переданы, до тех пор, пока не будет подтверждено их получение.
Брокеры сообщений работают по принципу асинхронного обмена сообщениями между приложениями. Эта модель предотвращает потерю ценных данных и поддерживает функционирование систем даже при нестабильной связи или высоких задержках, присущих общедоступным сетям.
Очередь сообщений
Очередь сообщений — вспомогательная структура или компонент, который хранит и упорядочивает сообщения, пока они не будут обработаны приложениями-получателями. Сообщения в очереди хранятся в том же порядке, в котором они были переданы, до тех пор, пока не будет подтверждено их получение.
Очередь сообщений повышает устойчивость архитектуры, поскольку сообщения могут сохраняться. Это означает, что они хранятся на диске до тех пор, пока служба, получающая сообщение, не подтвердит обработку. Очереди обмена сообщениями могут использоваться в сценариях, требующих высокого уровня безопасности, отказоустойчивости и точности, таких как обработка финансовых транзакций, бронирование авиабилетов или обновление записей пациентов здравоохранения.
Чем же так хороши очереди сообщений:
Надежная доставка сообщений: Использование очереди сообщений может гарантировать, что критически важные для бизнеса сообщения между приложениями не будут потеряны и что они будут доставлены получателю только один раз. При наличии этой функции дополнительная логика устранения дублирования или предотвращения потерь не требуется.
Взаимодействие между приложениями: Некоторые решения для очередей сообщений могут обрабатывать шифрование сообщений, транзакционность и другие аспекты связи между приложениями и службами. Это упрощает разработку приложений и позволяет различным архитектурам работать вместе.
Универсальность: Решения для очереди сообщений могут поддерживать несколько языков, таких как Java, Node.js, COBOL, C/C++, Go, .NET, Python, Ruby и C#. Они также могут поддерживать многочисленные интерфейсы прикладного программирования (API) и протоколы, включая MQTT, AMQP и REST, а также другие.
Устойчивость: Асинхронный обмен сообщениями гарантирует, что ошибки, связанные с конкретным приложением, не повлияют на систему. Если один компонент в системе останавливается, все остальные могут продолжать взаимодействовать с очередью и обрабатывать сообщения. Это уменьшает вероятность того, что сбой одной части повлияет на стабильность всей системы.
Улучшенная безопасность: очередь сообщений может идентифицировать и аутентифицировать все сообщения, а в некоторых решениях для очередей сообщений они могут быть настроены на шифрование сообщений в состоянии покоя, при передаче или из конца в конец. Это может способствовать общей безопасности приложений и/или инфраструктуры.
Модели брокеров сообщений
Двухточечный обмен сообщениями (point-to-point messaging)
Двухточечный обмен сообщениями: этот шаблон используется в очередях сообщений с прямой взаимосвязью между отправителем и получателем. Каждое сообщение в очереди отправляется только одному получателю, который получает его только один раз. Двухточечный обмен сообщениями предполагает только однократную обработку сообщения. В качестве варианта применения такого стиля может служить обработка платежей и финансовых транзакций. В таких системах и отправителю, и получателю нужна гарантия, что каждый платеж будет отправлен один и только один раз. Обработка таких транзакционных данных с использованием брокера сообщений дает гарантию, что платежная информация не будет ни потеряна, ни случайно продублирована; обеспечивает подтверждение получения и позволяет системам надежно взаимодействовать даже при сбоях в промежуточных сетях.
Примеры брокеров с явной моделью двухточечного обмена сообщениями:
RabbitMQ, Amazon SQS (Simple Queue Service), ActiveMQ / Artemis, IBM MQ (ранее известный как WebSphere MQ).
Модель издатель/подписчик (Pub/Sub)
этот шаблон обмена сообщениями часто сокращается до «pub/sub». Автор каждого сообщения публикует его в теме, а получатели (которых может быть несколько) подписываются на темы, из которых они хотят получать сообщения. Все опубликованные в теме сообщения отправляются во все подписанные на эту тему приложения. Это чем-то похоже на широковещание, когда между издателем и получателями сообщения установлена связь «один ко многим». Например, если авиакомпания будет рассылать новости о времени посадки или сроках задержки рейсов, то этой информацией могли бы пользоваться несколько сторон: наземные бригады, выполняющие техническое обслуживание и заправку самолетов, работники багажных служб, бортпроводники и пилоты, готовящиеся к следующему рейсу, и операторы табло для информирования пассажиров. Для таких ситуаций лучше всего подходит стиль издатель/подписчик.
Примеры брокеров сообщений с явной моделью издатель/подписчик:
Apache Kafka, Google Pub/Sub, Redis Pub/Sub, NATS / NATS JetStream
Сравнение с другими каналами связи
Брокеры сообщений и API
Для связи между микросервисами обычно используется REST API. Программный интерфейс приложений (API) указывает базовый код, который при условии соответствия правилам REST обеспечивает взаимодействие служб друг с другом. Но так как HTTP — это протокол запроса/ответа, то он лучше всего подходит для ситуаций, когда нужен асинхронный запрос/ответ. Это означает, что службы, отправляющие запросы через REST API, должны разрабатываться с расчетом на немедленный ответ. Если клиент не сможет принять ответ, то сервис, отправивший запрос, окажется заблокирован в ожидании ответа. В обе службы должна быть встроена логика аварийного переключения ресурсов и обработки ошибок. Брокеры сообщений обеспечивают асинхронный обмен сообщениями между службами, при котором отправителю не нужно ждать ответа получателя. Это повышает отказоустойчивость и надежность систем, в которых реализованы такие службы.
Сравнение с сервисной шиной предприятия
При использовании шины сообщений все службы или приложения должны совместно использовать общие типы данных, общий набор команд и общие протоколы связи (хотя они могут быть написаны на разных языках).
Брокеры сообщений — это «облегченная» альтернатива ESB практически с тем же функционалом (обмен информацией между службами), но гораздо проще и дешевле. Они хорошо подходят для архитектур на основе микросервисов, которые сейчас распространяются все больше, тогда как ESB теряют популярность.
Сравнение с БД и веб службы как альтернативы
Веб службы:
Приложения могут взаимодействовать напрямую через веб—службы или API на основе стандартных протоколов, таких как Протокол простого доступа к объектам (SOAP) или HTTP, а не через промежуточное программное обеспечение для обмена сообщениями. Веб-сервисы широко используются в распределенных системах, относительно просты и легки в реализации, что делает их жизнеспособной альтернативой очередям сообщений в определенных случаях использования и сценариях. Однако, в отличие от очередей сообщений, веб-службы не могут гарантировать доставку сообщений. Если сервер или соединение выходят из строя, необходимо создать возможности для обработки ошибки в клиенте. Веб-службам также не хватает моделей пабов/субдистрибуции. Промежуточное программное обеспечение для обмена сообщениями обеспечивает большую отказоустойчивость и лучшую способность обрабатывать интенсивный трафик или всплески активности.
Базы данных:
Базы данных могут использоваться в качестве альтернативы очередям сообщений в определенных ситуациях, но в большинстве случаев они служат разным целям и не являются легко взаимозаменяемыми. Базы данных чаще всего используются для хранения, и они позволяют вам снова и снова получать доступ к одной и той же информации. Очереди сообщений нельзя использовать для целей хранения. Как только сообщение было обработано, оно удаляется из очереди.
Создание функциональности, подобной очереди сообщений, в базе данных возможно, но это требует больших усилий по кодированию и знаний. Базы данных могут использоваться только для репликации простых структур очередей и не масштабируются для более крупных приложений.
Apache Kafka
Основная информация
(супер подробно на вкладке - “Курс по кафке”) Ссылка: Теория
Kafka — это распределенный реплицированный журнал фиксации изменений (commit log). Используется для мощных и нагруженных систем.
Распределенный, поскольку Kafka развертывается как кластер узлов, как для устойчивости к ошибкам, так и для масштабирования.
Реплицированный, поскольку сообщения обычно реплицируются на нескольких узлах (серверах).
Для защиты от сбоев у Kafka предусмотрена архитектура «ведущий—ведомый» на уровне раздела журнала, и в этой архитектуре ведущие называются лидерами, а ведомые еще могут называться репликами. Лидер каждого сегмента может иметь несколько ведомых. Если на сервере, где находится лидер, происходит сбой, предполагается, что реплика становится лидером и все сообщения сохраняются, только обслуживание на короткое время прерывается.
Журнал фиксации изменений, потому что сообщения хранятся в сегментированных, append-only (собирающих всю информацию) журналах, которые называются топиками.
Kafka обычно используется для сохранения и передачи событий, и он не включает в себя встроенного механизма retry. Однако, retry можно реализовать на уровне приложения или потребителя Kafka.
славится способностью поглощать и пересылать титанические объемы данных. В нём есть всё, что нужно для работы с высокими нагрузками: репликация, горизонтальное масштабирование, параллельная обработка потоков сообщений сразу на нескольких серверах.
ПОСЛЕ ПРОЧТЕНИЯ СООБЩЕНИЯ ПОЛЬЗОВАТЕЛЕМ – СООБЩЕНИЕ НЕ УДАЛЯЮТСЯ И ИХ МОЖНО ПРОЧИТАТЬ ЕЩЕ РАЗ;
Отправление сообщений может быть как синхронным, так и асинхронным. Какие варианты отправки у PRODUCER есть:
По умолчанию метод sent асинхронный («Fire and forget»), он максимально быстрый, но не дает никаких гарантий доставки, так как не ждем ответа о получении.
Второй просто асинхронный, то есть отправил и получил уведомление, что сообщение получено кафка и оно сохранилось. Он уже медленнее;
Третий вариант синхронный. Самый медленный, но самый надежный. Будем ждать уведомления об успешном сохранении сообщений и не делать ничего.
По работе с битыми сообщениями, можно использовать комбинированный подход, который включает в себя несколько шагов обработки битых сообщений. Вот пример такого подхода:
Попытка повторной обработки: При первой попытке обработки получатель пытается обработать сообщение. Если он не может это сделать из-за какой-либо временной проблемы или ошибки, получатель может попробовать обработать сообщение снова. Условно говоря, поставить кол-во попыток обработки (2 раза).
Логирование ошибки: Если сообщение не может быть обработано после заданного числа попыток, логируем ошибку;
Переадресация в очередь ошибок: После нескольких попыток обработки и логирования ошибки, получатель может отправить сообщение в специальную очередь или тему, где хранятся подобные сообщения, чтобы потом проверить эти ошибки уже с человеком.
Можно использовать простой подход, попытаться обработать сообщение несколько раз, не получается – логировать ошибку и пропускать такое битое сообщение.
Вместо того, чтобы помещать сообщения в очередь FIFO и отслеживать статус этого сообщения в очереди, как это делает RabbitMQ, Kafka просто добавляет его в журнал, и на этом всё, предоставляя получателю самому заботиться о получении нужной информации из топика. Сообщение остается, вне зависимости от того, будет ли оно получено один или несколько раз. Удаляется оно в соответствии с политикой удерживания данных (retention policy, также называемый window time period). Таким образом, Apache Kafka сохраняет текущее и все прежние состояния системы и может использоваться в качестве достоверного источника исторических данных, в отличие от RabbitMQ.
Каждый потребитель может читать данные из нескольких ящиков, куда кладутся сообщения и он должен помнить в какие ящики он уже заходил. То есть поставщик/потребитель сам должен ходить и спрашивать есть ли новые сообщения для него. Он должен запоминать номер сообщения – offset, который прочитал
Структура Кафки
Топики (topics) – категория, куда отправляются сообщения. В свою очередь, каждый топик разбивается на одну и более партицию. Топики могут быть реплицированы. У одного топика может быть несколько consumerов.
Партиция (partition) - Именно в партиции в итоге попадают события и пишутся сообщения. Если в кластере более одного брокера, то партиции будут распределены по всем брокерам равномерно (насколько это возможно), что позволит масштабировать нагрузку на запись и чтение в один топик сразу на несколько брокеров. Хранится по типу ключ-значение.
Уникальный идентификатор сообщения (offset) – у каждого сообщения свой уникальный ид в partition;
Поставщики (producer) – отправляют сообщения. Может просто отправить сообщение и дальше все, НО можно настроить, чтобы он получал уведомление о том, что сообщение положено в партицию. Но здесь может быть проблема, что это долго, например, есть много партиций и пока дождемся, что сообщение положено во все партиции будет долго (но можно настраивать кол-во сохранений в реплицированных партиций, например из 10 партиций, сохранить в 3). Также можно настроить сохранение только у лидера;
(consumer) – получатель сообщения/заказчик. Как правило, их могут объединить в группу. В таком случае читать из одной партиции может только один consumer из общей группы, другим consumer из этой группы нужно будет читать в других партициях.
Consumer сам запрашивает информацию у broker.
Кластер кафка (Broker) - Кафка работает в кластере, значит мы имеем один или несколько серверов, которые работают как единое целое;
Zookeeper — (в последних версия отсутствует) элемент выполняет роль хранилища метаданных и координатора. Это программа, которая управляет всем этим кластером. То есть может быть несколько очередей, которыми они управляются. Работает как база для хранения метаданных о состоянии узлов кластера и расположении сообщений. ZooKeeper обеспечивает гибкую и надежную синхронизацию в распределенной системе, позволяя нескольким клиентам выполнять одновременно чтение и запись. Что он делает, он контролирует то чтобы нейминг был уникальным (например 2 разных топика с одним названием), ip машин , чтобы они могли находить друг друга, контролирует очереди кафки итд.
Как это работает
Почтальон раскладывает по ящикам письма и нам эти письма необходимо забрать самостоятельно.
Каким же образом информация забирается из топика? Каждый получатель отслеживает, где она находится в журнале: имеется указатель на последнее полученное сообщение и этот указатель называется адресом смещения. Каждая партиция представляет собой отдельный файл, в котором гарантируется очередность сообщений.
Каждый логический тип событий обычно находится в своей отдельном топике (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) происходит как раз сегментами (нельзя удалить одно событие из партиции, можно удалить только целый сегмент, причём только неактивный).
Гарантии доставки в Kafka обеспечиваются:
долговечностью сообщений — сообщения, сохраненные в partition, не теряются;
уведомлениями о сообщениях — обмен сигналами между Kafka с одной стороны и источником/получателем — с другой.
Отказоустойчивость и высокая доступность в Apache Kafka
Здесь единицей репликации является раздел (partition). У каждого журнала (топика) есть один или несколько разделов. В каждом разделе есть лидер с фолловерами или без них. При создании топика указывается количество разделов и коэффициент репликации. Обычное значение 3, это означает три реплики: один лидер и два фолловера.
Серые PartitionFolower – резервные и они всегда получают данные от основного (зеленого), чтобы в случае, если он будет недоступен взять его функции на себя
Брокер сообщений RabbitMQ (для общего развития)
Немного о: RabbitMQ, Kafka, Redis, Memcached, NuxtJS, MongoDB, PostgreSQL
Брокер сообщений RabbitMQ | Tutorial для начинающих на русском | Урок 1 | Введение
Основная информация
RabbitMQ — программный брокер сообщений на основе протокола AMQP (Advanced Message Queuing Protocol) — тиражируемое связующее программное обеспечение, ориентированное на обработку сообщений. Устройство брокера упрощенно можно описать так:
есть Продюсер или поставщик сообщений, отправляющий события/сообщения. Здесь есть варианты по информации о получении:
fire and forget – продюсер просто отправил сообщение и дальше не интересуется ими вообще, то есть ему все равно. Это самый быстрый вариант;
получение принятия сообщения от брокера, это от точки обмена приходит информация, что сообщение успешно отправлено. И только после получения об успешной отправки, продюсер отправляет другое сообщение.
НО здесь есть вариант ОЖИДАЕМОЕ ПОДТВЕРЖДЕНИЕ, например 10. То есть продюсер отправляет одно сообщение за другим, до 10 и не ждет подтверждения. Как только цифра станет равной 10, то дальше он будет ждать, когда будет подтверждение о получении, чтобы можно было отправить сообщений еще;
точки обмена (exchange), в которое продюсер отправляет сообщение. Оно определяет в какую очередь будет отправлено сообщение. Для связи с очередью используются binding ключи;
очередь сообщений — своего рода «почтовый ящик», где хранятся сообщения. Работает по принципу FIFO (first input first output). Есть автоматическое восстановление очереди после сбоя. После прочтения consumer сообщения, это сообщение удаляется из очереди. Могут быть зеркалированные очереди, которые предназначены заменить основную, если основная (Мастер) очередь выйдет из строя;
подписчики/consumer, то есть программы — получатели сообщений.
в случае, если сообщение не удалось обработать получателем, например, получателю отправили сообщение несколько раз (2 раза), но сообщение битое, можно настроить отправку такого сообщения в специальную очередь (Dead Letter Exchanges (DLX)), где хранятся только битые сообщения и на такую очередь не подписан ни один получатель. Тогда получатель сможет получать только хорошие сообщения, а такие битые сообщения никто получать не будет, впоследствии, их можно будет просмотреть под админом, почему они были битые.
В очереди может храниться любое количество сообщений от неограниченного количества поставщиков, а получать их может неограниченное число подписчиков. RabbitMQ проталкивает сообщения при необходимости. Если очередь переполнена и получатель не может обработать сообщения, то задействуется дополнительная очередь, в которой будут храниться сообщения до тех пор, пока получатель их не получит.
Сам Rabbit не может преобразовывать сообщения, то есть переводить из json в xml – но если к нему прикрепить специальный адаптер, который умеет это делать, то он будет преобразовывать сообщения. RabbitMQ- предназначен для не самых высоких нагрузок.
Обычно работает как кластер узлов, где очереди распределяются по узлам и, опционально, реплицируются в целях устойчивости к ошибкам и высокой доступности.
отправители (publishers) отправляют сообщения на обменники (exchange);
обменники отправляют сообщения в очереди и в другие обменники;
при получении сообщения RabbitMQ отправляет подтверждения отправителям;
получатели (consumers) поддерживают постоянные TCP-соединения с RabbitMQ и объявляют, какую очередь они получают;
RabbitMQ проталкивает (push) сообщения получателям;
получатели отправляют подтверждения успеха или ошибки получения сообщения;
после успешного получения сообщение удаляется из очереди.
Работа Exchange (точек обмена)
Точка обмена в нее отправляются сообщения. Точка обмена распределяет сообщения в одну или несколько очередей. ПРИ этом в точке обмена сообщения не хранятся! Exchange удаляются после того как будут отписаны все очереди.
Точки обмена бывают трех типов:
Fanout –сообщение передается во все прицепленные к ней очереди;
Direc (маршрутизация по ключу)-сообщение передается в очередь с именем, совпадающим с ключом маршрутизации (routing key) и binding ключом очереди (ключ маршрутизации указывается при отправке сообщения);
Topic- сообщение передается в очереди для которых совпадает маска на ключ маршрутизации, например, app.motification.sms# - в очередь будут доставлены все сообщения, отправленные с ключами, начинающимися с app.motification.sms. Иными словами здесь допускается неполное совпадение этих ключей.
Header (заголовок) – настройка соответствия ключей либо полностью, либо частично. То есть здесь происходит опциональный выбор заранее.
В exchange может происходить некоторая маршрутизация. В Exchange есть набор для маршрутизации. То есть если продюсер хочет указать маршрутизировать сообщение, то в сообщение он прикладывает некоторую инфу - exchange читает эту информацию и делает следующее:
Гарантии доставки в RabbitMQ
надежностью сообщений — они не пропадут, пока хранятся на RabbitMQ;
уведомлениями о сообщениях — RabbitMQ обменивается сигналами с отправителями и получателями.
Очереди могут быть зеркалированы (реплицированы) на многих серверах. Следовательно, в случае зависания сервера вместо очереди на зависшем сервере предоставляется реплика этой очереди на другом сервере.
Отказоустойчивость и высокая доступность
В RabbitMQ два типа очереди: длительные/устойчивые (durable) и неустойчивые (non-durable).
Все очереди сохраняются в базе данных Mnesia. Устойчивые очереди повторно объявляются при запуске узла и, таким образом, переживают перезапуск, сбой системы или сбой сервера (до тех пор, пока сохраняются данные).
Зеркалирование очереди:
одна главная очередь (мастер), которая получает все команды на запись и чтение.
одно или несколько зеркал, которые получают все сообщения и метаданные из главной очереди. Эти зеркала существуют не для масштабирования, а исключительно для избыточности. То есть например, когда главное зеркало QueueMaster (зеленый) выйдет из строя, то существует балансировщик нагрузки, который переведет на другие зеркала (серые) потребителя, которые также получают данные. При создании нового зеркала все новые сообщения всегда будут реплицироваться на это зеркало и любые другие.
APACHE KAFKA VS RabbitMQ
https://tproger.ru/articles/pochemu-my-ispolzuem-kafka-vmesto-rabbitmq-sravnenie-i-preimushhestva
https://habr.com/ru/companies/beeline/articles/674328/
Основные отличия 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 — наоборот, «умный сервер, тупой клиент», поскольку этот брокер сам обеспечивает всю логику работы с сообщениями.