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

🎓 CS50: Архітектура ПЗ — Queues (Черги) та Routing задач

Привіт, друзі! 👋

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

Тема сьогоднішнього уроку: Queues (Черги) та Routing (Маршрутизація) задач.

1. 🔥 Вступ: Чому все "висить"?

Уявіть, що ви прийшли в популярну кав'ярню вранці. Ви підходите до каси, замовляєте складний лате з кокосовим молоком.

Сценарій А (Поганий дизайн): Касир приймає замовлення, бере гроші, а потім сам йде молоти каву, гріти молоко, малювати сердечко на пінці, мити чашку... І тільки коли він віддасть вам каву, він повертається до каси, щоб прийняти замовлення у наступної людини.

❓ Питання до вас: Що станеться з чергою людей на вулиці за 10 хвилин? Правильно. Вона буде кілометровою, а люди будуть люті.

Сценарій Б (Правильний дизайн): Касир тільки приймає замовлення і клеїть стікер на стаканчик. Цей стаканчик він ставить на стійку (в чергу). Інша людина (бариста) бере стаканчик і готує каву. Касир вже обслуговує наступного.

У програмуванні: * Касир — це ваш веб-сервер (API), який відповідає клієнту. * Стійка зі стаканчиками — це Queue (Черга). * Бариста — це Worker (Воркер), який робить важку роботу.

Навіщо нам це? Якщо ваш сайт обробляє завантаження відео, надсилання важких звітів чи генерацію PDF — ви не можете змушувати користувача дивитися на спінер завантаження 30 секунд. Ви маєте сказати: "Окей, я прийняв задачу, ми надішлемо результат пізніше", і відпустити користувача.

2. 🧠 Теоретична база: Що "під капотом"?

Давайте заглянемо всередину цієї "стійки з кавою".

У світі комп'ютерних наук ця схема називається Asynchronous Messaging (Асинхронний обмін повідомленнями). Тут є три головні дійові особи. Запам'ятайте їх:

Producer (Виробник) — Той, хто створює задачу (наприклад, ваш сайт, коли користувач натиснув "Купити").
Broker (Брокер) — Це "посередник" або сама черга. Це програма (наприклад, RabbitMQ, Redis, Amazon SQS), яка зберігає задачі й гарантує, що вони не загубляться.
Consumer / Worker (Споживач) — Програма, яка висить у фоні, забирає задачі з брокера і виконує їх.

Що таке Routing (Маршрутизація)?

Але що, якщо задач багато і вони різні? Уявіть, що на кухні ресторану є потік замовлень. * "Салат Цезар" → має йти до цеху холодних закусок. * "Стейк Рібай" → має йти до гарячого цеху (гриль).

Якщо ви відправите стейк кухарю, який ріже салати, буде біда.

Routing — це процес сортування задач у різні черги, щоб їх забрали правильні воркери. * Direct (Прямий): Чітко за адресою (Помилки → в лог помилок). * Fanout (Віяло): Одна подія → всім підряд (Користувач зареєструвався → і лист відправити, і в аналітику записати, і бонус нарахувати).

3. 🧪 Приклади (Код і логіка)

Давайте подивимося на це очима розробника. Будемо використовувати псевдокод на Python.

Приклад 1: Синхронний код (Як робити НЕ треба для важких задач)

def buy_ticket(user):
    # 1. Записуємо в БД
    db.save_order(user)

    # 2. Відправляємо PDF на пошту (ЦЕ ДОВГО! 5-10 секунд)
    email_service.send_ticket_pdf(user) 

    # Користувач чекає всі ці 10 секунд...
    return "Вітаємо з покупкою!"

❓ Що ви очікуєте? Якщо поштовий сервіс "впаде" або затупить, наш сайт перестане продавати квитки.

Приклад 2: Асинхронний код з чергою

# PRODUCER (Веб-сервер)
def buy_ticket(user):
    # 1. Швидко пишемо в БД
    db.save_order(user)

    # 2. Кидаємо задачу в чергу і забуваємо
    queue.publish(task="send_email", payload=user)

    # 3. Миттєво відповідаємо
    return "Замовлення прийнято! Квиток скоро буде на пошті."

# -------------------------------

# WORKER (Десь на іншому сервері)
def worker_process():
    while True:
        # Чекає задачу...
        task = queue.get() 
        if task:
            # Робить важку роботу
            email_service.send_ticket_pdf(task.user)
            # Каже брокеру: "Я все зробив, видаляй задачу"
            queue.ack(task)

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

Приклад 3: Routing (Маршрутизація)

Уявіть, що у нас складна система логування.

error (критично) → треба слати SMS адміну.
info (не критично) → просто записати у файл.

# PRODUCER
# Routing Key - це як адреса на конверті
broker.publish(message="База даних впала!", routing_key="critical_error")
broker.publish(message="Користувач зайшов на сайт", routing_key="user_action")

# WORKER 1 (SMS-сервіс)
# Підписаний тільки на "critical_error"
if routing_key == "critical_error":
    send_sms_to_admin(message)

# WORKER 2 (Файл-логер)
# Підписаний на ВСЕ ("#")
write_to_file(message)

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

Час "забруднити руки". Спробуйте вирішити ці ситуації (усно або на папері):

Завдання 1: Чорна п'ятниця У вас інтернет-магазин. У звичайний день працює 1 воркер, який обробляє замовлення. Настає Чорна п'ятниця, замовлень стає у 100 разів більше. Черга росте. * Завдання: Що треба зробити з воркерами, не змінюючи код основного сайту (Producer)?

Завдання 2: "Зламана задача" Воркер бере задачу "Обробити фото", починає її робити, і на середині процесу сервер воркера вимикається (зникає світло). * Завдання: Що станеться з цією задачею, якщо ми використовуємо правильний брокер? Вона зникне чи повернеться в чергу? (Підказка: згадайте термін ACK — acknowledgement).

Завдання 3: Routing для новин У вас є підписники, які хочуть новини тільки про "Спорт", і є ті, хто хоче про "Політику". * Завдання: Який Routing Key ви присвоїте новині про перемогу футбольної збірної? Як налаштувати черги, щоб ця новина потрапила тільки до фанатів спорту?

Завдання 4 (З зірочкою ⭐): Дедлайн Ви відправили задачу в чергу "Згенерувати звіт". Але воркери дуже завантажені. Задача пролежала в черзі 2 години. Користувачу цей звіт вже не потрібен. * Завдання: Як реалізувати механізм "терміну придатності" (TTL - Time To Live) задачі?

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

Як думає Senior Developer, коли проектує таку систему?

"Чи має ця задача бути виконана ПРЯМО ЗАРАЗ?" Якщо ні (надсилання пошти, генерація тумбнейлів, аналітика) — завжди виносимо в чергу. Це золоте правило продуктивності.
"Що, якщо воркер впаде?" Новачки часто думають, що код виконується ідеально. Досвідчені знають: мережа моргне, пам'ять закінчиться, API відпаде.
- Порада: Ваші задачі мають бути ідемпотентними. Це страшне слово означає: якщо одну й ту ж задачу виконати двічі (наприклад, воркер впав, не встиг прозвітувати, і задачу взяв інший воркер), нічого поганого не станеться. (Клієнт не отримає два квитки, з його картки не спишеться двічі).
Моніторинг — це все. Черга — це як труба. Якщо ви не бачите, скільки там води, її може розірвати. Завжди слідкуйте за довжиною черги.

6. 🧩 Підсумок

Отже, що ми сьогодні зрозуміли:

Decoupling (Розчеплення): Ми розділили прийом замовлення (Web) і його виконання (Worker).
Queues (Черги): Дозволяють згладжувати пікові навантаження.
Routing: Дозволяє направляти різні задачі різним виконавцям.

Тепер ви вмієте будувати системи, які не "падають", коли приходить тисяча користувачів, а спокійно кажуть: "Ставайте в чергу, ми всіх обслужимо".

🚀 Тизер наступного уроку: Ми навчилися розкладати задачі по чергах. Але що, якщо нам потрібно, щоб одна задача виконувалася щодня рівно о 9:00? Або раз на тиждень? На наступному уроці ми поговоримо про Cron Jobs та планування задач у часі.

Це був CS50. Щасти вам з кодом!