Державний університет «Одеська Політехніка»

Інститут комп’ютерних систем

Кафедра інформаційних систем

Реферат
з дисципліни «Технології комп'ютерного проектування»

Тема: «Порівняння RabbitMQ і Kafka»

Виконала:
студентка групи АИ-202
Полянський М.О.
Перевірив:
Іванов О. В.

Одеса 2022
 Зміст
Вступ.........................................................................................................................3
1. RabbitMQ............................................................................................................4
1.1 Exchange'і та черги......................................................................................4
1.2 Гарантії...........................................................................................................7
1.3 Проштовхування (push) та попередня вибірка одержувачів.....................8
1.4 Маршрутизація..............................................................................................8
1.5 Exchange з недоставленими повідомленнями...........................................11
1.6 Обмінники та черги без даних...................................................................11
2. Apache Kafka....................................................................................................12
2.1 Партиції та групи одержувачів..................................................................15
2.2 Проштовхування (push) проти вивантаження (pull)................................17
2.3 Публікація та підписка................................................................................18
2.4 Стиснення журналу.....................................................................................22
3. Докладніше про впорядкування повідомлень..............................................23
Висновки................................................................................................................24

2
 Вступ

Розсилка повідомлень (messaging) — центральна частина багатьох

архітектур, і двома стовпами у цій сфері є RabbitMQ та Apache Kafka. На
даний момент Apache Kafka стала практично індустріальним стандартом у
обробці даних та аналітиці, тому в цій реферативній роботі детально
розглянемо RabbitMQ та Kafka у контексті їх використання

3
 1. RabbitMQ

RabbitMQ – це розподілена система управління чергою

повідомлень. Розподілена, оскільки зазвичай працює як кластер вузлів, де
черги розподіляються по вузлах і, опціонально, реплікуються з метою
стійкості до помилок та високої доступності. Штатно, вона реалізує AMQP
0.9.1 та пропонує інші протоколи, такі як STOMP, MQTT та HTTP через
додаткові модулі.

RabbitMQ використовує як класичний, так і новаторський підходи до

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

1.1 Exchange'і та черги

 Паблішери (publishers) відправляють повідомлення на exchange'і

 Exchange'и відправляють повідомлення в черги та інші exchange'и

 RabbitMQ відправляє підтвердження паблішерам при отриманні

повідомлення

 Одержувачі (consumers) підтримують постійні TCP-з'єднання з

RabbitMQ і оголошують, яку чергу(-і) вони отримують

 RabbitMQ проштовхує (push) повідомлення одержувачам

4
  Одержувачі надсилають підтвердження успіху/помилки

 Після успішного отримання повідомлення видаляються з черг

У цьому списку приховано величезну кількість рішень, які повинні

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

Давайте подивимося приклад роботи з одним паблішером, exchange'м,

чергою та одержувачем:

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

Що робити, якщо у вас кілька паблішерів одного

повідомлення? Що робити, якщо ми маємо кілька одержувачів, кожен з яких
хоче отримувати всі повідомлення?

Рис. 2. Декілька паблішерів, кілька незалежних одержувачів

Як ви можете бачити, паблішери відправляють свої повідомлення на

той самий обмінник, який відправляє кожне повідомлення в три черги, у
кожній з яких є один отримувач. У випадку RabbitMQ черги дозволяють
різним одержувачам отримувати всі повідомлення. Порівняйте з діаграмою
нижче:
5
 Рис. 3. Декілька паблішерів, одна черга з декількома конкуруючими
одержувачами

На малюнку 3 бачимо трьох одержувачів, які використовують одну

чергу. Це одержувачі, що конкурують, тобто вони конкурують за отримання
повідомлень з черги. Таким чином, очікується, що в середньому кожен
одержувач отримуватиме одну третину повідомлень з черги. Ми
використовуємо конкуруючих одержувачів для масштабування нашої
системи обробки повідомлень, а за допомогою RabbitMQ зробити це дуже
просто: додайте або видаліть одержувачів на запит. Незалежно від того,
скільки у вас конкуруючих одержувачів, RabbitMQ забезпечить доставку
повідомлень лише одному одержувачу.

Ми можемо скомбінувати рис. 2 та 3, щоб отримати кілька наборів,

конкуруючих одержувачів, де кожен набір отримує кожне повідомлення.

6
 Рис. 4. Кілька паблішерів, кілька черг із конкуруючими одержувачами

Стрілки між обмінниками та чергами називаються прив'язками

(bindings), і ми ще поговоримо про них докладніше.

1.2 Гарантії

RabbitMQ дає гарантії «одноразової доставки» і «хоча однієї доставки»,

але не «рівно однієї доставки».

Примітка перекладача: до версії Kafka 0.11 доставка повідомлень

exactly-once delivery була недоступна, в даний час подібна функціональність
є і в Kafka.

Повідомлення доставляють у порядку їх прибуття в чергу (зрештою, це

і є визначення черги). Це не гарантує, що завершення обробки повідомлень
збігається з тим самим порядком, коли у вас є конкуруючі одержувачі. Це не
помилка RabbitMQ, а фундаментальна реальність паралельної обробки
впорядкованого набору повідомлень. Цю проблему можна вирішити,

7
використовуючи Consistent Hashing Exchange, як ви побачите в наступному
розділі шаблонів і топологій.

1.3 Проштовхування (push) та попередня вибірка одержувачів

RabbitMQ проштовхує (push) повідомлення одержувачам (є також API

для вивантаження (pull) повідомлень з RabbitMQ, але зараз ця
функціональність застаріла). Це може переповнити одержувачів, якщо
повідомлення прибудуть до черги швидше, ніж одержувачі можуть їх
обробити. Щоб цього уникнути, кожен одержувач може налаштувати межу
попередньої вибірки (також відомий як межа QoS). По суті, межа QoS це
обмеження на кількість непідтверджених одержувачем повідомлень. Це як
запобіжник, коли одержувач починає відставати.

Навіщо прийнято рішення про те, що повідомлення у черзі

проштовхуються (push), а не вивантажуються (pull)? По-перше, тому, що так
менший час затримки. По-друге, в ідеалі, коли ми маємо конкуруючі
одержувачі з однієї черги, ми хочемо рівномірно розподілити навантаження
між ними. Якщо кожен одержувач запитує/вивантажує повідомлення, то
залежно від того, скільки вони запитують, розподіл може стати досить
нерівномірним. Чим нерівномірніший розподіл повідомлень, тим більша
затримка та подальша втрата порядку повідомлень під час обробки. Ці
фактори орієнтують архітектуру RabbitMQ на механізм проштовхування
"одно-повідомлення-за-раз". Це одне з обмежень масштабування
RabbitMQ. Обмеження пом'якшується тим, що підтвердження можна
групувати.

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

Exchange — це, в основному, маршрутизатори повідомлень для черг

та/або інших exchange'ів. Щоб повідомлення переміщалося з exchange'а у

8
чергу або на інший exchange, потрібна прив'язка. Різні exchange'и вимагають
різних прив'язок. Існує чотири типи Exchange і пов'язані з ними прив'язки:

 Fanout (розгалужувальний). Спрямовує у всі черги та обмінники, що

мають прив'язку до exchange'у Стандартна підмодель Pub.

 Direct (прямий). Маршрутизує повідомлення на основі ключа

маршрутизації, який несе із собою повідомлення, задається
паблішером. Ключ маршрутизації – короткий рядок. Прямі обмінники
надсилають повідомлення в черги/exchange'і, які мають ключ
сполучення, який точно відповідає ключу маршрутизації.

 Topic (тематичний). Маршрутизує повідомлення на основі ключа

маршрутизації, але дає змогу використовувати неповну відповідність
(wildcard).

 Header (заголовний). RabbitMQ дозволяє додавати до повідомлень

заголовки одержувачів. Заголовкові exchange'і передають повідомлення
відповідно до цих значень заголовка. Кожна прив'язка включає точну
відповідність значень заголовка. До прив'язки можна додати кілька
значень із БУДЬ-ЯКИМИ або ВСІМИ значеннями, необхідними для
відповідності.

 Consistent Hashing (консистентне хешування). Це обмінник, який хешує

або ключ маршрутизації, або заголовок повідомлення, і надсилає лише
одну чергу. Це корисно, коли вам потрібно дотриматися гарантії
порядку обробки і при цьому мати можливість масштабувати
одержувачів.

9
 Рис. 5. Приклад topic exchange'а

У цьому прикладі паблішери публікують журнали помилок за

допомогою формату ключа маршрутизації LEVEL (Рівень помилки).
AppName.

Черга 1 отримуватиме всі повідомлення, оскільки використовує №

підстановочного знака з кількома словами.

Черга 2 отримає будь-який рівень ведення журналу

ECommerce.WebUI. Вона використовує wildcard *, таким чином захоплюючи
рівень одного іменування топіка (ERROR.Ecommerce.WebUI,
NOTICE.ECommerce.WebUI і тп).

У черзі 3 будуть відображатися всі повідомлення рівня ERROR з будь-

якої програми. Вона використовує wildcard # для охоплення всіх програм
(ERROR.ECommerce.WebUi, ERROR.SomeApp.SomeSublevel ітп).

Завдяки чотирьом способам маршрутизації повідомлень та з

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

10
1.5 Exchange з недоставленими повідомленнями

Примітка перекладача: Коли повідомлення з черги не можуть бути

отримані з тих чи інших причин (потужності споживачів не вистачає,
мережеві проблеми тощо), їх можна відкладати та обробляти окремо.

Ми можемо налаштувати черги так, щоб повідомлення надсилалися на

exchange за наступних умов:

 Черга перевищує задану кількість повідомлень.

 Черга перевищує задану кількість байт.

 Час надсилання повідомлення (TTL) закінчився. Паблішер може

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

Ми створюємо чергу, яка має прив'язку до exchange'ів з

недоставленими повідомленнями, і ці повідомлення зберігаються там до тих
пір, поки не буде здійснено будь-яку дію.

Як і багато функцій RabbitMQ, exchange'і з недоставленими

повідомленнями дають можливість використовувати шаблони, які
непередбачені спочатку. Ми можемо використовувати TTL повідомлень та
exchange'и з недоставленими повідомленнями для реалізації відкладених черг
та повторних черг.

1.6 Обмінники та черги без даних

Exchange і черги можуть бути створені динамічно, при цьому можна

задати критерії для їх автоматичного видалення. Це дозволяє
використовувати такі шаблони як черги відповідей для RPC на основі
повідомлень.

11
 2. Apache Kafka

Kafka – це розподілений реплікований журнал фіксації змін (commit

log). У Kafka'і немає концепції черг, що спочатку може здатися дивним,
враховуючи, що його використовують як систему обміну
повідомленнями. Черги довгий час були синонімом систем обміну
повідомленнями. Давайте спочатку розберемося, що означає «розподілений,
реплікований журнал фіксації змін»:

 Розподілений, оскільки Kafka розгортається як кластер вузлів як для

стійкості до помилок, так і для масштабування

 Реплікований, оскільки повідомлення зазвичай реплікуються на

кількох вузлах (серверах).

 Журнал фіксації змін, тому що повідомлення зберігаються в

сегментованих, append-only журналах, які називаються топіками. Ця
концепція журналування є основною унікальною перевагою Kafka.

Розуміння журналу (і топіка) та партицій є ключем до розуміння

Kafka. Отже, чим партійний журнал відрізняється від набору черг? Давайте
уявімо, як це виглядає.

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

12
 Замість того, щоб розміщувати повідомлення в чергу FIFO і
відстежувати статус цього повідомлення в черзі, як це робить RabbitMQ,
Kafka просто додає його до журналу, і на цьому все.

Повідомлення залишається незалежно від того, чи буде воно отримане

один або кілька разів. Видаляється воно відповідно до політики утримування
даних (retention policy, також званий window time period). Яким чином
інформація забирається з топіка?

Кожен отримувач відстежує, де вона знаходиться в журналі: є

вказівник на останнє отримане повідомлення і цей вказівник називається
адресою усунення. Одержувачі підтримують цю адресу через клієнтські
бібліотеки, і залежно від версії Kafka адреса зберігається або в ZooKeeper,
або в Kafka'і.

Відмінна риса моделі журналювання в тому, що вона миттєво усуває

безліч складнощів, що стосуються стану доставки повідомлень і, що більш
важливо для одержувачів, дозволяє їм перемотувати назад, повертатися та
отримувати повідомлення за попередньою відносною адресою. Наприклад,
уявіть, що ви розгортаєте сервіс, який виставляє рахунки, що враховують
замовлення, які клієнти розміщують. У служби трапилася помилка, і вона
неправильно розраховує всі рахунки за 24 години. З RabbitMQ у кращому
випадку вам потрібно буде якось опублікувати ці замовлення тільки на
сервісі рахунків. Але з Kafka ви просто переміщаєте відносну адресу для
цього одержувача на 24 години тому.

Отже, давайте подивимося, як це виглядає, коли є топік, в якому є одна

партиція та два одержувачі, кожен з яких має отримати кожне повідомлення.

13
 Рис. 7. Один продюсер, одна партиція, два незалежні одержувачі

Як видно з діаграми, два незалежні одержувачі отримують одну й ту

саму партицію, але читають за різними адресами усунення. Можливо,
обслуговування виставлення рахунків довше обробляє повідомлення, ніж
служба пуш-нотифікацій. або, можливо, сервіс виставлення рахунків був
недоступний якийсь час і намагався наздогнати вже пізніше. Або, може, була
помилка, і адресу усунення довелося відкласти на кілька годин.

Тепер припустимо, що сервіс виставлення рахунків необхідно

розділити на три частини, тому що вона не може встигнути за швидкістю
повідомлення. З RabbitMQ ми просто розвертаємо ще дві програми-сервіси
виставлення рахунків, які отримують із черги обслуговування рахунків. Але
Kafka не підтримує конкуруючих одержувачів в одній партиції, блок
паралельності Kafka це сама партиція. Тому, якщо нам потрібні три
отримувачі рахунків, нам потрібні як мінімум три партиції. Отже, тепер ми
маємо:

14
 Рис. 8. Три партиції та дві групи по три отримувачі

Таким чином, мається на увазі, що вам потрібно як мінімум стільки ж

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

2.1 Партиції та групи одержувачів

Кожна партиція є окремим файлом, у якому гарантується черговість

повідомлень. Це важливо пам'ятати: порядок повідомлень гарантується лише
в одній партиції. Надалі це може призвести до деякої суперечності між
потребами у черговості повідомлень та потребами у продуктивності, оскільки
продуктивність у Kafka також масштабується партіціями. Партиція не може

15
підтримувати конкуруючих одержувачів, тому наш додаток для виставлення
рахунків може використовувати лише одну частину кожного розділу.

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

алгоритму або через функцію хешування: hash (message key) % кількість
партицій. Використання функції хешування має деякі переваги, оскільки ми
можемо створювати ключі повідомлень, щоб повідомлення від одного
об'єкта, наприклад інформація про бронювання, яка повинна бути оброблена
послідовно, завжди переходили в один сегмент. Це дозволяє
використовувати багато шаблонів роботи з чергами та гарантії черговості
повідомлень.

Групи одержувачів подібні до конкуруючих одержувачів

RabbitMQ. Кожен одержувач у групі є частиною однієї програми та
оброблятиме підмножину всіх повідомлень у темі. У той час, як усі
конкуруючі одержувачі RabbitMQ отримують з однієї черги, кожен
одержувач у групі одержувачів отримує з різних партій однієї і тієї ж
теми. Таким чином, у наведених вище прикладах всі три частини служби
рахунків належать одній і тій же групі одержувачів.

Поки що RabbitMQ виглядає трохи гнучкішою системою з його

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

Існує неявна, але важлива перевага, яка була у Kafka з самого початку,
а в RabbitMQ додалося пізніше – черговість повідомлень та
паралелізм. RabbitMQ підтримує глобальний порядок усієї черги, але не
пропонує способу підтримувати це розташування під час її паралельної
обробки. Kafka не може запропонувати глобальне розташування топіка, але
пропонує черговість на рівні партиції. Тому, якщо вам потрібно тільки
вибудовувати черговість пов'язаних повідомлень, Kafka пропонує як

16
впорядковану доставку повідомлень, так і впорядковану обробку
повідомлень.

Уявіть, що ви маєте повідомлення, які показують останній стан

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

Ця можливість існує і в RabbitMQ – за допомогою Consistent Hashing

exchange, який однаково розподіляє повідомлення по чергах. Однак
особливість Kafka'і полягає в тому, що Kafka організує цю впорядковану
обробку таким чином, що тільки один одержувач у кожній групі може
отримати повідомлення з однієї партиції, і спрощує роботу, оскільки, щоб
забезпечити дотримання цього правила, для вас всю роботу виконує вузол -
координатор. У RabbitMQ все одно можуть бути конкуруючі одержувачі, які
отримують одну чергу від партиції, і вам доведеться переконатися, що цього
не відбувається.

Тут також є підводні камені: в той момент, коли ви змінюєте кількість

партій, повідомлення з номером Id 1000 тепер переходять в іншу партію,
тому повідомлення з номером Id 1000 існують у двох партицях. Залежно від
того, як ви обробляєте повідомлення, це може спричинити проблему. Тепер є
сценарії, коли повідомлення обробляються не по порядку.

2.2 Проштовхування (push) проти вивантаження (pull)

17
 RabbitMQ використовує модель проштовхування (push) і, таким чином,
перевантаження повідомлень одержувачами за допомогою налаштованої
одержувачем межі попередньої вибірки. Це чудово підходить для обміну
повідомленнями з низьким значенням затримки та добре працює для
архітектури RabbitMQ на основі черги. З іншого боку, Kafka використовує
модель витягування (pull), де одержувачі вимагають партії повідомлень із
заданого відносного усунення. Щоб уникнути нескінченних порожніх циклів,
коли жодних повідомлень не існує за межами поточної відносної адреси,
Kafka припускає long-polling.

Модель витягування (pull) має сенс для Kafka через його

сегменти. Оскільки Kafka гарантує порядок повідомлень у партиції без
одержувачів конкуруючих, ми можемо вигідно застосувати пакетування
повідомлень для більш ефективної доставки повідомлень, що дає нам більш
високу пропускну здатність.

Це не має особливого значення для RabbitMQ, тому що в ідеалі ми

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

2.3 Публікація та підписка

Kafka підтримує базовий шаблон продюсер/передплатник з деякими

додатковими шаблонами, пов'язаними з тим, що це журнал і він має
партиції. Продюсери додають повідомлення в кінець розділів журналу, і
одержувачів з їх відносними адресами можна розмістити будь-де партиції.

18
 Рис. 9. Одержувачі з різними відносними адресами

Цей стиль діаграми не так легко інтерпретувати, коли є кілька парицій

та груп одержувачів, тому для решти діаграм для Kafka я використовуватиму
наступний стиль:

Рис. 10. Один продюсер, три партиції та одна група з трьох одержувачів

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

одержувачів, оскільки є партиції:

19
Рис. 11. Деякі одержувачі зчитують із кількох партій

Одержувачі в одній групі одержувачів будуть координувати отримання

партицій, гарантуючи, що одна партиція не буде отримана більш ніж одним
одержувачем тієї ж групи одержувачів.

Аналогічно, якщо у нас більше одержувачів, ніж партицій, додатковий

одержувач залишатиметься бездіяльним у резерві.

20
 Рис. 12. Один бездіяльний одержувач

Після додавання та видалення одержувачів група одержувачів може

стати незбалансованою. Перебалансування перерозподіляє одержувачів за
партиціями якомога рівномірніше.

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

 одержувач приєднується до групи одержувачів

 одержувач йде з групи одержувачів (у разі, коли він відключається або

починає вважатися непрацюючим)

21
  додано нові партиції

Перебалансування спричинить короткий період додаткової затримки у

доступі до даних, тоді як одержувачі перестануть читати партії повідомлень і
будуть розміщені в різні партиції. Будь-який стан даних у пам'яті, яке
підтримувалося одержувачем, тепер може стати недійсним.

Одна з моделей отримання Kafka - це здатність направити всі

повідомлення даного об'єкта, наприклад, бронювання, в ту саму партицію і,
отже, тому самому одержувачу. Це називається локальністю даних. При
перебалансуванні даних будь-які дані в пам'яті про ці дані будуть марними,
якщо одержувач не буде розміщений у тій же партиції. Тому одержувачі, які
підтримують стан, повинні зберігатись зовнішнім чином.

2.4 Стиснення журналу

Стандартна політика зберігання даних – це політика на основі часу та

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

Уявімо, що ми отримуємо повідомлення, що містить стан бронювання

користувача. Щоразу, коли відбувається зміна бронювання, генерується нова
подія з поточним станом бронювання. Цей топік може мати кілька
повідомлень для цього одного бронювання, які представляють стан цього
бронювання з моменту його створення. Після того, як топік буде стиснутий,
буде збережено тільки останнє повідомлення, пов'язане з цим бронюванням.

Залежно від кількості бронювань та розміру кожного бронювання, ви

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

22
 3. Докладніше про впорядкування повідомлень
Ми розглянули, що масштабування та підтримка порядку повідомлень
одночасно можливе як з RabbitMQ, так і з Kafka, але з Kafka це набагато
простіше. З RabbitMQ ми повинні використовувати консистентне хешування
та вручну впроваджувати логіку групи одержувачів, використовуючи
розподілений узагальнений сервіс, такий як ZooKeeper або Consul.

Але RabbitMQ має одну цікаву можливість, якої немає у Kafka. Це не є

особливістю самої RabbitMQ, а будь-якої системи обміну повідомленнями,
що базується на черзі на основі підписки. Можливість така: системи обміну
повідомленнями на основі черги дають змогу передплатникам
упорядковувати довільні групи подій.

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

розділяти чергу між собою, тому що вони будуть конкурувати за отримання
повідомлень. Їм потрібна їхня власна черга. Це дає програмам свободу
конфігурувати свою чергу будь-яким чином, яким вони вважають за
потрібне. Вони можуть направити кілька типів подій з кількох топиків у свою
чергу. Це дозволяє програмам підтримувати впорядкування пов'язаних
подій. Ті події, які потрібно об'єднати, можуть бути налаштовані по-різному
для кожної програми.

Це просто неможливо за допомогою системи обміну повідомленнями

на основі журналу, як Kafka, оскільки журнали є спільними
ресурсами. Кілька програм читають один журнал. Таким чином, будь-яке
угруповання пов'язаних подій в одній темі є рішенням, прийнятим на
ширшому рівні архітектури системи.

Таким чином, тут переможець не є очевидним. RabbitMQ дозволяє

підтримувати відносний порядок у довільних наборах подій, а Kafka
забезпечує простий спосіб підтримки впорядкування із підтримкою
масштабування.

23
 Висновки

RabbitMQ пропонує широкий спектр шаблонів обміну повідомленнями

завдяки безлічі функціональних можливостей, які він має. Завдяки своїй
повнофункціональній маршрутизації він може позбавити одержувачів
необхідності вилучати, десеріалізувати і перевіряти кожне повідомлення,
коли йому потрібно тільки підмножина. З ним легко працювати,
масштабування вгору та вниз здійснюється шляхом простого додавання та
видалення одержувачів. Його архітектура додаткових модулів дозволяє йому
підтримувати інші протоколи та додавати нові функції, такі як консистентне
хешування обмінів, що є важливим доповненням.

Розподілений журнал Kafka з відносними адресами одержувачів

уможливлює подорож у часі. Його можливість маршрутизувати
повідомлення з тим самим ключем одному й тому ж отримувачу, у свою
чергу уможливлює надзвичайно паралелізовану впорядковану
обробку. Стиснення журналу Kafka та збереження даних дозволяють
створювати нові шаблони, які RabbitMQ просто не може виконати. Нарешті,
хоча Kafka може масштабуватися більше, ніж RabbitMQ, більшість із нас має
справу з таким обсягом повідомлень, який обидва підходи можуть обробити
без проблем.

24