PHP. RABBITMQ
  • Introduction
  • publish/subscribe. Deliver to multiple consumers
  • routing
  • RPC
Powered by GitBook
On this page

Was this helpful?

Introduction

Nextpublish/subscribe. Deliver to multiple consumers

Last updated 5 years ago

Was this helpful?

Ідемо далі!

Спочатку познайомлюся з основами:

Publisher ніколи не використовує queue напряму - він використовує exchange - такий собы роутер

1) Fanout - посилає сообщеніє всім консюмерам.

4) Header - посилає заголовок письма замість routing key

Базові приклади Hello World:

sender:

Тепер розглянемо приклад queue:

task:

АЛЕ ЩО ЯКЩО НАШ ВОРКЕР ПОМРЕ НЕ ВИКОНАВШИ ТАСКУ ДО КІНЦЯ?

Ми втратимо message і таска не буде виконана! Це недопустимо, і ми хочемо зробити так, що якщо воркер помре ця таска відправиться на обробку у інший воркер!

Це рішається тим, що консюмер відправляє в кінці сообщеніє про то, що таска виконана. Таким чином message ніколи не втрачаються!

Також дуже важливо розуміти, що ми не мусимо по черзі розсилати сообщенія у worker-и по принципу round robin. Ми можемо чекати поки worker звільниться і тільки тоді посилати у нього дані!

Exchange посилає повідомлення у потрібні чергиProducer мусить задачи routing key, у той час як Consumers можуть підписуватися на routing key завдяки binding_key:

Також є 4 типи які може паблішити Producer:

2) Direct - посилає сообщеніє по ключу (сообщеніє получають тільки ті консюмери, які підписалися на ключ):

3) Partial - ключ по регулярці якоби:

При чому дуже важно є наступне: Сообщеніє доставиться лише в 1 consumer по ключу. Тоєсть можна скейлити пріложуху і добавляти скільки завгодно однакових консюмерів.

receiver:

Ми розглянули базовий приклад Hello Worls для того щоб поняти як усе працює впринципі.

receiver:

Усе працює мега мощно, причому ми можемо добавляти скільки завгодно скріптів обработчиків (consumers), rabbit буде слати message лише в один з consumers, при чому попорядку і в тому порядку в якому consumers були добавлені. Це називається Round-Robin dispetching:

Таким чином завдяки MEssage Acknowledgments ми захищені від втрат messages із-за падіння воркерів.Також можна зробити так, що не тільки сообщенія не будуть тірятися якщо закриється worker процесс, а і очереді не будуть тірятися якщо rabbitmq вирубиться або перезагрузиться! ЦЕ ДУЖЕ ВАЖЛИВО - PERSISTANCE.