RabbitMQ

У системі, де програми викликають одна одну безпосередньо, відправник запиту зазвичай залежить від доступності одержувача. RabbitMQ додає між ними окремий програмний компонент — брокер повідомлень. Виробник публікує повідомлення брокеру, а споживач отримує його незалежно від того, чи працював він у момент публікації. Повідомлення може очікувати в черзі; однак його збереження після збою залежить від типу черги та налаштувань надійності.^[15]

Наприклад, після оформлення замовлення інтернет-магазин може створити повідомлення про нову покупку. Окремі служби опрацьовують оплату, складські операції або надсилання повідомлень покупцеві. За допомогою RabbitMQ можна розподілити завдання між працівниками або передати одну подію кільком незалежним службам — залежно від обраної схеми маршрутизації.^[4]

У моделі AMQP 0-9-1 взаємодія організована за допомогою таких об'єктів:^[4]

• Виробник (producer, publisher) — застосунок, який створює та публікує повідомлення.
• Повідомлення (message) — одиниця переданої інформації з даними та службовими властивостями. Дані можуть бути текстовими або двійковими, наприклад у форматі JSON чи XML.
• Точка обміну (exchange) — об'єкт, який приймає опубліковане повідомлення й за правилами маршрутизації спрямовує його до черг, потоків або інших точок обміну.
• Черга (queue) — структура для утримання повідомлень, які належить передати споживачам. У звичайній черзі успішно підтверджене повідомлення після оброблення вилучається.
• Споживач (consumer) — застосунок, який отримує повідомлення та обробляє їх.
• Прив'язка (binding) — зв'язок між точкою обміну та місцем призначення, іноді з умовою маршрутизації.
• Ключ маршрутизації (routing key) — рядок, що його публікатор передає разом із повідомленням. За певних типів точок обміну цей рядок визначає потрібні місця призначення.

Точки обміну, черги й прив'язки існують у межах віртуального хоста (virtual host, vhost). Віртуальні хости розділяють простори імен, налаштування та права доступу різних застосунків, але не означають фізично відокремленого обладнання або окремого процесу RabbitMQ.^[16]

На відміну від простої черги, до якої відправник звертається безпосередньо, модель AMQP 0-9-1 дозволяє публікувати повідомлення в точку обміну й налаштовувати доставлення без зміни відправника. Основні типи точок обміну:^[17]

Наприклад, прив'язка orders.created.* до точки обміну topic відбиратиме ключі orders.created.eu й orders.created.us, але не orders.cancelled.eu. При цьому одна подія може потрапити до кількох черг, якщо задовольняє умови відповідних прив'язок.^[17]

За замовчуванням RabbitMQ створює точку обміну direct з порожньою назвою, до якої кожна черга автоматично прив'язується за власним іменем. Це дає змогу публікувати повідомлення в конкретну чергу, використовуючи її назву як ключ маршрутизації.^[17]

• Розподіл роботи (work queue): кілька споживачів отримують повідомлення зі спільної черги, і зазвичай кожне повідомлення дістається одному з них.
• Публікація — підписка (publish/subscribe): повідомлення передаються кільком незалежним одержувачам, зазвичай через окремі черги.
• Маршрутизація за темами: підписники отримують лише повідомлення, ключі яких відповідають заданим шаблонам.
• Запит — відповідь (request/reply): застосунок надсилає запит та одержує відповідь іншим повідомленням. RabbitMQ має для цього, зокрема, механізм Direct Reply-To.^[4][18]

Класичні черги (classic queues) — початковий тип черг RabbitMQ. Вони підтримують звичайне доставлення повідомлень, підтвердження від споживача, обмеження часу життя й, за відповідної конфігурації, пріоритети. Починаючи з версії 4.0 вони не реплікуються між вузлами. Тому кластер із кількох вузлів не забезпечує автоматично збереження вмісту класичної черги після виходу з ладу її вузла.^[19]

Кворумні черги (quorum queues) призначені для реплікованого зберігання повідомлень. Вони застосовують алгоритм Raft — механізм розподіленого консенсусу, за яким репліки узгоджують послідовність записів. Один вузол виконує роль лідера, а для безпечного підтвердження запису необхідна більшість реплік.^[14]

Наприклад, кворумна черга з трьома репліками може продовжувати роботу після відмови однієї з них за умови збереження зв'язку між двома іншими. За втрати більшості така черга перестає приймати операції, для яких потрібен кворум. Реплікація підвищує стійкість до відмов, але створює додаткові навантаження на мережу й диски.^[14]

RabbitMQ Streams — структура даних для зберігання послідовності повідомлень як журналу з дописуванням у кінець (append-only log). На відміну від звичайної черги, прочитаний запис не вилучається відразу: кілька незалежних споживачів можуть читати ті самі дані, починати з певної позиції (offset) і повторювати читання. Записи видаляються відповідно до політик зберігання, наприклад за терміном або обсягом.^[13]

Потоки завжди зберігають дані на диску й підтримують реплікацію. Super streams об'єднують кілька потоків у логічну структуру, розділену на секції (partitions), для паралельного опрацювання. Потоки використовують, зокрема, для запису подій, їхнього повторного читання та передавання великого обсягу повідомлень.^[13]

^[7]

Для надійного обміну важливо розрізняти підтвердження прийняття повідомлення брокером (publisher confirms) й підтвердження оброблення повідомлення споживачем (consumer acknowledgements). Перше сигналізує відправникові, що брокер прийняв відповідальність за публікацію відповідно до властивостей місця призначення; друге дозволяє брокеру вважати конкретну доставку завершеною. Підтвердження публікації не засвідчує виконання бізнес-операції одержувачем.^[20]

Якщо споживач працює з ручними підтвердженнями і його з'єднання розривається до підтвердження, брокер може повернути непідтверджене повідомлення до черги й доставити його іншому споживачеві. Отже, програми мають передбачати повторне надходження тих самих повідомлень.^[20]

У RabbitMQ довговічність черги (durable queue) та стійкість повідомлення (persistent message) — різні налаштування. Для класичної черги, щоб повідомлення могло пережити перезапуск, важливі і довговічність черги, і спосіб публікації повідомлення. Кворумні черги використовують зберігання повідомлень на диску. Проте сама наявність дискового запису не скасовує необхідності належних підтверджень та врахування можливих відмов обладнання.^[15][19][14]

Для прикладної системи можна організувати доставлення не більш як один раз (at-most-once) або щонайменше один раз (at-least-once). Другий підхід допускає дублікати після збою. RabbitMQ не гарантує автоматично, що зовнішня дія — наприклад списання коштів чи запис у базу даних — відбудеться рівно один раз. Для цього розробники застосовують, зокрема, ідемпотентні операції або дедуплікацію подій.^[15][20]

Для відокремлення повідомлень, які не вдалося обробити звичайним способом, RabbitMQ підтримує точки обміну недоставлених повідомлень (dead-letter exchanges, DLX). До них повідомлення можуть бути скеровані після відхилення без повторного повернення, спливу строку життя, перевищення обмеження довжини черги або допустимого числа доставлень у кворумній черзі.^[21]

RabbitMQ також підтримує керування попереднім вибиранням повідомлень (prefetch), обмеження їхнього часу життя й повторне доставлення. Ці засоби допомагають уникнути неконтрольованого накопичення непідтверджених повідомлень і визначати поведінку програми під час збоїв.^[20][7]

Звичайні черги переважно працюють за принципом FIFO («першим надійшло — першим вибуло»). Однак паралельне опрацювання різними споживачами, пріоритети та повторні доставки можуть змінювати фактичний порядок завершення роботи. Якщо потрібна одна активна програма-споживач на чергу, можна застосувати режим Single Active Consumer.^[7]

Для PHP поширені два способи використання AMQP 0-9-1:

• php-amqplib — бібліотека, написана мовою PHP; не вимагає окремого розширення PHP.^[27]
• php-amqp — розширення PHP, що використовує бібліотеку librabbitmq для роботи з брокерами AMQP 0-9-1.^[28]