MQ
MQ - Message Queque⚑
Що таке MQ⚑
Черги повідомлень, по суті, є зв'язуючою ланкою між різними процесами у додатках та надають надійний та масштабований інтерфейс взаємодії з іншими підключеними системами та пристроями. Черга — структура даних з принципом доступу до елементів "перший прийшов — перший вийшов". Додавання елемента можливе лише в кінець черги, вибірка — лише з початку черги, при цьому вибраний елемент з черги видаляється.
Десять причин, чому черги повідомлень є життєво важливим компонентом для будь-якої архітектури чи додатка
- Слабке зв'язування — черги повідомлень створюють неявні інтерфейси обміну даними, які дозволяють процесам бути незалежними одне від одного, тобто ви просто визначаєте формат повідомлень, відправлених від одного процесу іншому.
- Надмірність — черги дозволяють уникнути випадків неефективного використання ресурсів процесу (наприклад, пам'яті) внаслідок зберігання невикористаної (надмірної) інформації.
- Масштабованість — черги повідомлень дозволяють розподілити процеси обробки інформації. Таким чином, вони дозволяють легко збільшувати швидкість, з якою повідомлення додаються в чергу та обробляються.
- Еластичність та можливість витримувати пікові навантаження — черги повідомлень можуть виконувати роль свого роду буфера для накопичення даних в разі пікового навантаження, згладжуючи таким чином навантаження на систему обробки інформації та запобігаючи її відмові.
- Стійкість до відмов — черги повідомлень дозволяють розділити процеси один від одного, так що якщо процес, який обробляє повідомлення з черги, падає, повідомлення можуть бути додані в чергу для обробки пізніше, коли система відновиться.
- Гарантована доставка — використання черг повідомлень гарантує, що повідомлення буде доставлено та оброблено в будь-якому випадку (поки є принаймні один обробник).
- Гарантований порядок доставки — більшість систем черг повідомлень здатні забезпечити гарантії того, що дані будуть оброблятися у певному порядку (найчастіше у порядку їх надходження).
- Буферизація — черги повідомлень дозволяють відправляти та отримувати повідомлення, при цьому працюючи з максимальною ефективністю, надаючи буферний шар — процес запису в чергу може відбуватися настільки швидко, наскільки це може робити черга повідомлень, а не обробник повідомлення.
- Розуміння потоків даних — черги повідомлень дозволяють виявляти вузькі місця в потоках даних додатка, легко можна визначити, яка з черг заповнюється, яка не використовується, і визначити, що необхідно робити — додавати нових обробників повідомлень або оптимізувати поточну архітектуру.
- Асинхронний зв'язок — черги повідомлень надають можливість асинхронної обробки даних, що дозволяє помістити повідомлення в чергу без обробки, дозволяючи системі обробити повідомлення пізніше, коли з'явиться можливість.
Які готові реалізації MQ ви знаєте⚑
- RabbitMQ: Це відкрите програмне забезпечення, яке реалізує стандартизований протокол AMQP (Advanced Message Queuing Protocol). Він дозволяє надійно та масштабовано обмінюватися повідомленнями між різними системами та компонентами додатків.
- Apache Kafka: Це розподілена платформа для потокової обробки та зберігання даних. Він спроектований для обробки великої кількості подій (повідомлень) та забезпечує гарантовану доставку та зберігання цих подій.
- Redis: Redis може бути використаний як MQ за допомогою свого механізму публікації-підписки (pub-sub) та черги повідомлень (list). Він швидкий та легкий у використанні.
- Apache ActiveMQ: Це ще одна реалізація протоколу AMQP. Він надає різноманітні можливості обробки повідомлень, включаючи публікацію-підписку, черги повідомлень та багато іншого.
- ZeroMQ (0MQ): Це бібліотека для передачі повідомлень між процесами через різні протоколи. Вона дозволяє вам побудувати власні механізми обміну повідомленнями, а також підходить для складних топологій зв'язку.
- Apache RocketMQ: Це система повідомлень, яка забезпечує надійну та масштабовану передачу повідомлень між різними компонентами додатків.
Links
- Message middleware deployment and comparison: rabbitMQ, activeMQ, zeroMQ, rocketMQ, Kafka, redis
- RabbitMQ против Kafka: два разных подхода к обмену сообщениями
- Kafka VS RabbitMQ
- Выбор MQ для высоконагруженного проекта
Який життєвий цикл повідомлення в MQ ?⚑
- Створення повідомлення: Відправник (producer) генерує повідомлення та відправляє його в чергу через брокер обміну або API сервісу.
- Доставлення в чергу: Повідомлення додається до черги. У RabbitMQ це може бути зв'язано з маршрутизатором (exchange), який спрямовує повідомлення в одну чи кілька черг відповідно до правил маршрутизації.
- Зберігання повідомлення: Повідомлення зберігається в черзі до моменту, коли споживач (consumer) зможе його обробити. Для RabbitMQ можна налаштувати TTL (time-to-live) для повідомлень. В AWS SQS можна використовувати Dead Letter Queue для обробки невдалих повідомлень.
- Отримання повідомлення: Споживач зчитує повідомлення з черги. У RabbitMQ це відбувається шляхом підтвердження доставки (acknowledgment), що забезпечує надійність. В AWS SQS споживач блокує повідомлення (visibility timeout) для запобігання його повторному зчитуванню іншими споживачами.
- Обробка повідомлення: Споживач виконує необхідну логіку для обробки повідомлення. Наприклад, це може бути виклик функції або запис даних у базу.
- Видалення повідомлення: Після успішної обробки споживач підтверджує RabbitMQ або видаляє повідомлення з черги в AWS SQS. В Azure Service Bus використовується подібний підхід із механізмом підтвердження.
- Помилки обробки: Якщо повідомлення не може бути оброблене, воно може бути відправлене в Dead Letter Queue (у AWS SQS та Azure Service Bus) або повернене в RabbitMQ для повторної обробки залежно від налаштувань.