Модуль 3

Message broker та backend результатів

Ось урок, створений спеціально для тебе у стилі CS50: енергійний, з живими прикладами та фокусом на розумінні суті.

🎓 УРОК: Message Broker та Backend Результатів

(або Як не змушувати користувача чекати)

Привіт, друзі! Радий бачити вас на занятті.

1. 🔥 Вступ: проблема та мотивація

Уявіть собі ситуацію. Ви заходите на популярний сайт, щоб згенерувати складний звіт за рік, або, скажімо, обробити велике відео. Ви натискаєте кнопку «Обробити» і... чекаєте.

Крутиться колесо завантаження. Секунда... п'ять... десять... тридцять. Браузер зависає. Ви нервуєте. Нарешті — «Помилка 504 Gateway Timeout». Сервер втомився чекати й розірвав з'єднання. Знайомо?

Питання до вас: Чому так сталося? Тому що ваш запит (HTTP) і виконання завдання (обробка відео) були пов’язані "намертво". Ви змусили веб-сервер, який має швидко віддавати сторінки, займатися важкою атлетикою.

Це якби ви прийшли в McDonald’s, замовили 50 бургерів, і касир особисто пішов їх смажити, поки вся черга за вами стоїть і чекає. Це неефективно. Це катастрофа для бізнесу.

Як це виправити? Нам потрібен посередник. Нам потрібна система, яка скаже касиру: "Прийми замовлення, видай чек і обслуговуй наступного. А бургери ми посмажимо на фоні".

Саме тут на сцену виходять герої нашого уроку: Message Broker (Брокер повідомлень) та Result Backend (Бекенд результатів). Без них не існує жодного сучасного Instagram, Uber чи Telegram.

2. 🧠 Теоретична база (А що там під капотом?)

Давайте розберемо це на простій аналогії кухні ресторану.

У нас є 4 дійові особи:

  1. Producer (Продюсер/Клієнт): Це ваш веб-сайт або додаток. Він каже: "Треба надіслати email" або "Треба стиснути картинку".
  2. Message Broker (Брокер): Це дошка із замовленнями на кухні. Продюсер ліпить туди стікер із завданням. Брокер — це черга (Queue). Його робота — надійно зберігати повідомлення, поки їх хтось не забере.
    • Популярні інструменти: RabbitMQ, Redis, Apache Kafka.
  3. Consumer / Worker (Воркер/Робітник): Це кухар. Він дивиться на дошку (Брокер), бачить стікер, забирає його і починає готувати. Він працює окремо від касира!
  4. Result Backend (Сховище результатів): Це полиця видачі, куди кухар кладе готову страву. Коли завдання виконане, воркер пише туди: "Статус: Готово, ось посилання на звіт".
    • Популярні інструменти: Redis, база даних (PostgreSQL), Memcached.

⚙️ Як це працює технічно:

  1. Користувач тисне кнопку.
  2. Ваш сервер (Producer) формує повідомлення (зазвичай це JSON: {"task": "resize_image", "id": 123}).
  3. Сервер кидає це повідомлення в Брокер і миттєво каже користувачеві: "Завдання прийнято! ID твого замовлення — 123. Перевіримо пізніше".
  4. На фоні прокидається Воркер, бере повідомлення з Брокера, робить важку роботу.
  5. Воркер записує результат у Result Backend.
  6. Користувач (або його браузер) періодично запитує: "Замовлення 123 готове?". Коли в Result Backend з'являється "Готово", користувач отримує результат.

❗️ Що треба запам'ятати залізобетонно: Веб-сервер (Producer) і Воркер (Consumer) нічого не знають одне про одного. Вони спілкуються ТІЛЬКИ через Брокера. Це називається Decoupling (слабка зв'язність).

3. 🧪 Приклади (Від простого до реального)

Приклад 1: Надсилання Email при реєстрації

Уявіть код без брокера:

def register_user(email):
    save_to_db(email)
    send_welcome_email(email) # Це займає 2-3 секунди!
    return "Ви зареєстровані"

Користувач чекає 3 секунди. Це довго.

А тепер з Брокером (Celery + Redis):

def register_user(email):
    save_to_db(email)
    # Ми просто кидаємо задачу в чергу. Це займає 0.001 секунди.
    send_email_task.delay(email) 
    return "Ви зареєстровані! (лист прийде скоро)"

Результат: Миттєва відповідь. Лист відправляється окремим процесом.

Приклад 2: Генерація PDF-квитка

Ситуація: Ви купуєте квиток на потяг. Система має згенерувати PDF.

  1. Крок 1: Ви оплачуєте. Сервер створює task_id.
  2. Крок 2: Задача потрапляє в Redis (Broker).
  3. Крок 3: Воркер забирає задачу, малює PDF, заливає його на S3 (хмарне сховище).
  4. Крок 4: Воркер пише в Redis (Result Backend): task_id: {status: "SUCCESS", url: "https://.../ticket.pdf"}.
  5. Крок 5: Ваш фронтенд кожні 2 секунди пінгує бекенд. Як тільки бачить статус SUCCESS — показує кнопку "Завантажити квиток".

Запитання: Що буде, якщо Воркер "впаде" (вимкнеться світло) під час генерації PDF? Відповідь: Хороший Брокер побачить, що Воркер не відзвітував про успіх, і через певний час (timeout) поверне задачу назад у чергу. Її підхопить інший Воркер. Система надійна!

4. 🛠 Практична частина

Час розім'яти мізки. Ось вам завдання:

🔹 Завдання 1: Намалюй схему На аркуші або в голові побудуй ланцюжок для Instagram: Користувач завантажує фото -> Накладається фільтр -> Фото зберігається. Де тут Producer, Broker, Worker і Result Backend?

🔹 Завдання 2: "Пляшкове горлечко" У вас 1000 замовлень в секунду (Producer працює швидко), але лише 1 Воркер, який обробляє 1 замовлення за 10 секунд. Що станеться з Брокером? (Підказка: Пам'ять брокера переповниться чергою). Як це вирішити? (Додати більше Воркерів!).

🔹 Завдання 3: Міні-кейс Ви робите сайт для конвертації відео в MP3. * Користувач завантажив файл. * Ви показали йому прогрес-бар "0%". * Як реалізувати оновлення прогрес-бару до 100%? Хто і куди має писати відсотки?

🔹 Завдання 4: А що, якщо... Що, якщо ми використовуємо Redis і як Брокер, і як Result Backend? Чи це нормально? (Так, для малих та середніх проектів це стандартна практика. Redis дуже швидкий).

5. 💡 Мислення як у розробника

Як відрізнити новачка від профі в цій темі?

❌ Помилка новачка: Використовувати базу даних (SQL) як чергу. "Я створю таблицю Tasks і буду робити SELECT * FROM Tasks WHERE status='new' кожні 5 секунд". Це вбиває базу даних! Бази не люблять постійного читання-запису-блокування. Для цього придумали спеціалізовані Брокери (Redis, RabbitMQ).

❌ Помилка новачка №2: Забувати про Result Backend. Ви запустили задачу, вона порахувалася... і результат зник у нікуди, бо ви не сказали, куди його покласти.

🧠 Як думає Senior: 1. Асинхронність за замовчуванням. Якщо дія триває довше 0.5 секунди — я виношу її у фон. 2. Масштабованість. Якщо черга росте, я просто запускаю ще 5 контейнерів з Воркерами. Код змінювати не треба! 3. Ідемпотентність. (Страшне слово, просте значення). Що буде, якщо воркер випадково обробить одну задачу двічі? Я маю написати код так, щоб це не зняло гроші з клієнта двічі.

6. 🧩 Підсумок

Отже, що ми сьогодні розібрали?

  1. Producer віддає задачу і не чекає.
  2. Broker (черга) тримає задачу.
  3. Worker виконує задачу на фоні.
  4. Result Backend зберігає відповідь.

Тепер ви вмієте проектувати системи, які не "туплять", навіть коли роблять дуже важку роботу. Ви розділили "прийом замовлення" і "приготування їжі".

🚀 Тизер наступного уроку: Окей, ми запустили 10 воркерів, брокер, базу даних... У нас купа процесів. Як це все запустити однією командою і не збожеволіти? На наступному уроці ми поговоримо про Docker та Docker Compose — магічні контейнери для нашого зоопарку сервісів.

А поки — це був CS50. Побачимось! 👋

← До списку уроків Наступний урок →