Главная » Хабрахабр » RabbitMQ против Kafka: два разных подхода к обмену сообщениями

RabbitMQ против Kafka: два разных подхода к обмену сообщениями

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

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

Источник

RabbitMQ vs Kafka

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

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

Что интересно, у каждой системы свои преимущества, но при этом они довольно сильно отличаются друг от друга. Таким образом, в нашей серии статей мы не будем говорить о случаях когда требуется экстремальная масштабируемость (и это прерогатива Kafka), а сосредоточимся на уникальных преимуществах, которые предлагает каждая из рассматриваемых систем. Мне нравится хорошо сделанные вещи, а RabbitMQ и Kafka обе вполне зрелые, надежные и, да, масштабируемые messaging-системы. Я, конечно, довольно много писал про RabbitMQ, но уверяю, что никакого особого предпочтения ей не отдаю.

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

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

RabbitMQ

Распределенная, поскольку обычно работает как кластер узлов, где очереди распределяются по узлам и, опционально, реплицируются в целях устойчивости к ошибкам и высокой доступности. RabbitMQ — это распределенная система управления очередью сообщений. 9. Штатно, она реализует AMQP 0. 1 и предлагает другие протоколы, такие как STOMP, MQTT и HTTP через дополнительные модули.

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

Exchange'и и очереди

Супер-упрощенный обзор:

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

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

Давайте посмотрим пример работы с одним паблишером, exchange’м, очередью и получателем:

1.
Рис. Один паблишер и один получатель

Что делать, если у нас есть несколько получателей, каждый из которых хочет получать все сообщения? Что делать, если у вас несколько паблишеров одного и того же
сообщения?

2.
Рис. Несколько паблишеров, несколько независимых получателей

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

3.
Рис. Несколько паблишеров, одна очередь с несколькими конкурирующими получателями

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

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

4.
Рис. Несколько паблишеров, несколько очередей с конкурирующими получателями

Стрелки между обменниками и очередями называются привязками (bindings), и мы еще поговорим о них подробнее.

Гарантии

RabbitMQ дает гарантии «одноразовой доставки» и «хотя бы одной доставки», но не «ровно одной доставки».

11 доставка сообщений exactly-once delivery была недоступна, в настоящее время подобная функциональность присутствует и в Kafka.
Примечание переводчика: до версии Kafka 0.

Это не гарантирует, что завершение обработки сообщений совпадает с тем же самым порядком, когда у вас есть конкурирующие получатели. Сообщения доставляются в порядке их прибытия в очередь (в конце концов, это и есть определение очереди). Эту проблему можно решить, используя Consistent Hashing Exchange, как вы увидите в следующей главе по шаблонам и топологиям. Это не ошибка RabbitMQ, а фундаментальная реальность параллельной обработки упорядоченного набора сообщений.

Проталкивание (push) и предварительная выборка получателей

Это может переполнить получателей, если сообщения прибудут в очередь быстрее, чем получатели могут их обработать. RabbitMQ проталкивает (push) сообщения получателям (существует также API для выгрузки (pull) сообщений из RabbitMQ, но в настоящий момент эта функциональность устарела). По сути, предел QoS это ограничение на количество скопившихся неподтвержденных получателем сообщений. Чтобы этого избежать, каждый получатель может настроить предел предварительной выборки (также известный как предел QoS). Это действует как предохранитель, когда получатель начинает отставать.

Во-первых, потому, что так меньше время задержки. Зачем принято решение о том, что сообщения в очереди проталкиваются (push), а не выгружаются (pull)? Если каждый получатель запрашивает/выгружает сообщения, то в зависимости от того, сколько они запрашивают, распределение работы может стать довольно неравномерным. Во-вторых, в идеале, когда у нас есть конкурирующие получатели из одной очереди, мы хотим равномерно распределить нагрузку между ними. Эти факторы ориентируют архитектуру RabbitMQ на механизм проталкивания “одно-сообщение-за-раз”. Чем более неравномерно распределение сообщений, тем больше задержка и дальнейшая потеря порядка сообщений во время обработки. Ограничение смягчается тем, что подтверждения можно группировать. Это одно из ограничений масштабирования RabbitMQ.

Маршрутизация

Чтобы сообщение перемещалось из exchange’а в очередь или на другой exchange, необходима привязка. Exchange’и — это, в основном, маршрутизаторы сообщений для очередей и/или других exchange’ей. Существует четыре типа exchange’ей и связанные с ними привязки: Разные exchange’и требуют разных привязок.

  • Fanout (разветвляющий). Направляет во все очереди и обменники, имеющие привязку к exchange’у Стандартная подмодель Pub.
  • Direct (прямой). Маршрутизирует сообщения на основе ключа маршрутизации, который несет с собой сообщение, задается паблишером. Ключ маршрутизации — короткая строка. Прямые обменники отправляют сообщения в очереди/exchange’и, у которых есть ключ сопряжения, который точно соответствует ключу маршрутизации.
  • Topic (тематический). Маршрутизирует сообщения на основе ключа маршрутизации, но позволяет использовать неполное соответствие (wildcard).
  • Header (заголовочный). RabbitMQ позволяет добавлять к сообщениям заголовки получателей. Заголовочные exchange’и передают сообщения в соответствии с этими значениями заголовка. Каждая привязка включает в себя точное соответствие значений заголовка. К привязке можно добавить несколько значений с ЛЮБЫМИ или ВСЕМИ значениями, необходимыми для соответствия.
  • Consistent Hashing (консистентное хэширование). Это обменник, который хэширует либо ключ маршрутизации, либо заголовок сообщения, и отправляет только в одну очередь. Это полезно, когда вам нужно соблюсти гарантии порядка обработки и при этом иметь возможность масштабировать получателей.

5.
Рис. Пример topic exchange’а

В этом примере паблишеры публикуют журналы ошибок с использованием формата ключа маршрутизации LEVEL(Уровень ошибки). Мы еще рассмотрим маршрутизацию более подробно, но выше приведен пример topic exchange’а. AppName.

Очередь 1 будет получать все сообщения, так как использует № подстановочного знака с несколькими словами.

WebUI. Очередь 2 получит любой уровень ведения журнала приложения ECommerce. Ecommerce. Она использует wildcard *, таким образом захватывая уровень одного именования топика (ERROR. ECommerce. WebUI, NOTICE. WebUI итп).

Она использует wildcard # для охвата всех приложений (ERROR. В очереди 3 будут отображаться все сообщения уровня ERROR из любого приложения. WebUi, ERROR. ECommerce. SomeSublevel итп). SomeApp.

Дальше мы поговорим об exchange’ах с недоставленными сообщениями (dead letter exchange), об exchange’ах и очередях без данных (ephemeral exchanges and queues), и RabbitMQ развернется в полную мощь. Благодаря четырем способам маршрутизации сообщений и с возможностью exchange-ам передавать сообщения на другие exchange’и RabbitMQ позволяет использовать мощный и гибкий набор шаблонов обменов сообщениями.

Exchange’и с недоставленными сообщениями

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

Мы можем настроить очереди так, чтобы сообщения отсылались на exchange при следующих условиях:

  • Очередь превышает заданное количество сообщений.
  • Очередь превышает заданное количество байт.
  • Время передачи сообщения (TTL) истекло. Паблишер может установить время жизни сообщения, и сама очередь тоже может иметь заданное TTL для сообщения. В таком случае будет использоваться более короткий TTL из двух.

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

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

Обменники и очереди без данных

Это позволяет использовать такие шаблоны, как очереди ответов для RPC на основе сообщений. Exchange’и и очереди могут быть созданы динамически, при этом можно задать критерии для их автоматического удаления.

Дополнительные модули

Он очень прост в установке и у него простой в использовании интерфейс. Первый подключаемый модуль, который вы наверняка захотите установить — это плагин управления, который предоставляет HTTP-сервер с веб-интерфейсом и REST API. Развертывание сценариев через REST API тоже очень простое.

Кроме того:

  • Consistent Hashing Exchange, Sharding Exchange и многое другое
  • протоколы, такие как STOMP и MQTT
  • веб-хуки
  • дополнительные типы обменников
  • интеграция SMTP

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

Apache Kafka

У Kafka’и нет концепции очередей, что сначала может показаться странным, учитывая, что его используют в качестве системы обмена сообщениями. Kafka — это распределенный реплицированный журнал фиксации изменений (commit log). Давайте для начала разберемся, что значит «распределенный, реплицированный журнал фиксации изменений»: Очереди долгое время были синонимом систем обмена сообщениями.

  • Распределенный, поскольку Kafka развертывается как кластер узлов, как для устойчивости к ошибкам, так и для масштабирования
  • Реплицированный, поскольку сообщения обычно реплицируются на нескольких узлах (серверах).
  • Журнал фиксации изменений, потому что сообщения хранятся в сегментированных, append-only журналах, которые называются топиками. Эта концепция журналирования является основным уникальным преимуществом Kafka’и.

Итак, чем партиционированный журнал отличается от набора очередей? Понимание журнала (и топика) и партиций являются ключом к пониманию Kafka’и. Давайте представим, как это выглядит.

6 Один продюсер, один сегмент, один получатель
Рис.

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

Удаляется оно в соответствии с политикой удерживания данных (retention policy, также называемый window time period). Сообщение остается, вне зависимости от того, будет ли оно получено один или несколько раз. Каким же образом информация забирается из топика?

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

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

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

7.
Рис. Один продюсер, одна партиция, два независимых получателя

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

С RabbitMQ мы просто разворачиваем еще два приложения-сервиса выставления счетов, которые получают из очереди обслуживания счетов. Теперь предположим, что сервис выставления счетов необходимо разделить на три части, потому что она не может поспеть за скоростью сообщения. Поэтому, если нам нужны три получателя счетов, нам нужно как минимум три партиции. Но Kafka не поддерживает конкурирующих получателей в одной партиции, блок параллельности Kafka — это сама партиция. Итак, теперь у нас есть:

8.
Рис. Три партиции и две группы по три получателей

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

Партиции и группы получателей

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

Использование функции хэширования имеет некоторые преимущества, поскольку мы можем создавать ключи сообщений, чтобы сообщения от одного объекта, например, информация о бронированиях, которая должна быть обработана последовательно, всегда переходили в один сегмент. Сообщения могут быть перенаправлены на сегменты по циклическому алгоритму или через функцию хэширования: hash (message key) % количество партиций. Это позволяет использовать многие шаблоны работы с очередями и гарантии очередности сообщений.

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

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

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

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

Однако особенность Kafka’и заключается в том, что Kafka организует эту упорядоченную обработку таким образом, что только один получатель в каждой группе может получить сообщения из одной партиции, и упрощает работу, поскольку, чтобы обеспечить соблюдение этого правила, для вас всю работу выполняет узел-координатор. Эта возможность существует и в RabbitMQ — с помощью Consistent Hashing exchange, который одинаково распределяет сообщения по очередям. В RabbitMQ все равно могут быть конкурирующие получатели, получающие одну очередь от партиции, и вам придется убедиться, что этого не происходит.

В зависимости от того, как вы обрабатываете сообщения, это может вызвать проблему. Здесь также есть подводные камни: в тот момент, когда вы меняете количество париций, сообщения с номером Id 1000 теперь переходят в другую партицию, поэтому сообщения с номером Id 1000 существуют в двух партициях. Теперь существуют сценарии, когда сообщения обрабатываются не по порядку.

Проталкивание (push) против выгрузки (pull)

Это отлично подходит для обмена сообщениями с низким значением задержки и хорошо работает для архитектуры RabbitMQ на основе очереди. RabbitMQ использует модель проталкивания (push) и, таким образом, перегрузку сообщений получателями с помощью настроенного получателем предела предварительной выборки. Чтобы избежать бесконечных пустых циклов, когда никаких сообщений не существует за пределами текущего относительного адреса, Kafka допускает long-polling. С другой стороны, Kafka использует модель вытягивания (pull), где получатели запрашивают партии сообщений с заданного относительного смещения.

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

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

Публикация и подписка

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

9.
Рис. Получатели с различными относительными адресами

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

10. Рис. Один продюсер, три партиции и одна группа из трех получателей

Нет необходимости иметь такое же количество получателей в нашей группе получателей, поскольку есть партиции:

11.
Рис. Некоторые получатели считывают из нескольких партиций

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

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

12.
Рис. Один бездействующий получатель

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

Перебалансировка автоматически запускается после того как:

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

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

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

Сжатие журнала

Например, хранение до последней недели сообщений или до 50 ГБ. Стандартная политика хранения данных — это политика на основе времени и пространства. Когда журнал сжимается, результатом является то, что сохраняется только последнее сообщение для каждого ключа сообщения, остальные удаляются. Но существует другой тип политики хранения данных – сжатие журнала.

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

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

Подробнее об упорядочении сообщений

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

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

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

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

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

Выводы

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

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

В следующей части мы более подробно рассмотрим шаблоны обмена сообщениями и топологии с RabbitMQ.

Присоединяйтесь: t.me/justiothings Завели, кстати, тематический чат в телеграме про IoT и все, что с этим связано.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Явные возможности JavaScript

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

Особенности работы в интернациональной команде. Япония

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