Ось готовий урок, створений у стилі Девіда Малана (CS50), адаптований під твій запит.

🎓 УРОК CS50-style: Архітектура систем (Producer, Consumer, Queue)

Привіт, друзі! Ласкаво просимо. Сьогодні ми не просто пишемо код — ми вчимося будувати системи, які не ламаються під тиском.

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

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

Питання до вас: Що станеться, якщо до касира підійде черга з 20 людей?

Касир швидко наб’є замовлення і побіжить на кухню кричати кухарю: "Печи Маргариту! А тепер Пепероні! А тепер Чотири сири!". Кухар у паніці, він ще першу не допік. Касир не може приймати нові замовлення, поки не передасть попереднє кухарю в руки. Клієнти зляться. Бізнес горить (буквально).

У програмуванні це називається синхронне виконання. Коли один процес (сайт) чекає, поки інший (сервер відправки пошти / генератор PDF / обробник відео) закінчить роботу.

Чому без цієї теми не обійтись? Бо в реальному світі (Netflix, Uber, Instagram) задачі надходять швидше, ніж ми можемо їх обробити. Нам потрібен буфер. Нам потрібен спосіб сказати: "Я прийняв твоє замовлення, іди гуляй, ми надішлемо сповіщення, коли буде готово".

Сьогодні ми розберемо патерн, який рятує сервери від смерті: Producer — Queue — Consumer.

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

Давайте розберемо нашу піцерію на технічні терміни. Це база, на якій тримається весь Backend-розробка високого навантаження.

Три кити (Definitions):

Producer (Виробник) 🏭
- Це той, хто створює задачу. У нашому прикладі — це Касир.
- У коді: це веб-сервер, який каже "Користувач зареєструвався, треба надіслати йому email".
Queue (Черга) 📥
- Це буфер. Тимчасове сховище. У піцерії — це рейка з чеками на кухні.
- Касир чіпляє туди чек і забуває про нього. Він може приймати нових клієнтів.
- Головне правило: FIFO (First In, First Out) — хто перший прийшов, того першого й обслужили (зазвичай).
Consumer (Споживач / Воркер) 👷
- Це той, хто виконує важку роботу. У нас — це Кухар.
- Він не дивиться на Касира. Він дивиться на Чергу (рейку). Взяв чек -> пік піцу -> взяв наступний.

Як це працює (Інтуїтивно):

Уявіть це як конвеєр. * Синхронно: Ви даєте завдання і чекаєте, поки його зроблять, дивлячись в очі виконавцю. * Асинхронно (через чергу): Ви кидаєте завдання в кошик "Зробити" і йдете далі. Виконавець підходить до кошика, коли вільний.

❗️ Що треба запам'ятати залізно: Producer і Consumer не знають один про одного. Вони "спілкуються" тільки з чергою. Це називається Decoupling (слабка зв'язність). Це дозволяє нам додати ще 5 кухарів (Consumers), і касиру (Producer) не треба буде нічого змінювати у своїй роботі.

3. 🧪 Приклади (Python Edition)

Давайте подивимось, як це виглядає в коді. Використаємо стандартну бібліотеку Python, щоб зрозуміти логіку.

Приклад 1: Проста черга (FIFO)

Уявіть список задач.

import queue

# Створюємо чергу (наша рейка для чеків)
order_queue = queue.Queue()

# --- PRODUCER (Касир) ---
print("🍕 Касир: Прийняв замовлення на Маргариту")
order_queue.put("Маргарита")

print("🍕 Касир: Прийняв замовлення на Пепероні")
order_queue.put("Пепероні")

# --- CONSUMER (Кухар) ---
# Що ви очікуєте побачити зараз, якщо кухар візьме задачу?
# Правильно, "Маргарита", бо вона була першою.

current_order = order_queue.get()
print(f"👨‍🍳 Кухар: Готую {current_order}...")

current_order = order_queue.get()
print(f"👨‍🍳 Кухар: Готую {current_order}...")

Приклад 2: Реальна імітація (з потоками)

У житті процеси йдуть паралельно. Поки кухар готує, касир не спить.

import threading
import time
import queue
import random

q = queue.Queue()

def producer():
    # Імітуємо наплив клієнтів
    orders = ["Маргарита", "Гавайська", "Карбонара", "4 Сири"]
    for order in orders:
        print(f"📥 [Producer] Отримав замовлення: {order}")
        q.put(order)
        time.sleep(1) # Клієнти приходять раз на секунду

def consumer():
    while True:
        # Кухар бере замовлення
        order = q.get()
        if order is None: break # Сигнал зупинки

        print(f"🔥 [Consumer] Почав готувати: {order}")
        time.sleep(3) # Готувати довго (3 секунди)!
        print(f"✅ [Consumer] {order} готова!")

        q.task_done() # Повідомляємо чергу, що задачу закрито

# Запускаємо
# Дивіться уважно: Producer буде "накидувати" швидше, ніж Consumer розгрібає.
# Черга буде рости!
t1 = threading.Thread(target=consumer)
t2 = threading.Thread(target=producer)

t1.start()
t2.start()

Чому результат такий? Ви побачите, що Producer накидав 4 замовлення за 4 секунди, а Consumer ще возиться з першим. Але система не впала! Замовлення надійно лежать у пам'яті (у черзі) і чекають.

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

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

🔹 Повторення: Запустіть код із Прикладу 2. Змініть час сну (sleep) так, щоб Кухар працював швидше за Касира. Що зміниться в логах?
🔹 Масштабування: Уявіть, що ми найняли другого кухаря. Додайте ще один потік (Thread) для функції consumer. Як тепер обробляються замовлення? Чи швидше черга стає порожньою?
🔹 Виправлення помилки: Що буде, якщо під час приготування піци (всередині consumer) станеться помилка (наприклад, raise Exception("Тісто впало"))? Чи позначиться задача як виконана (task_done)? Як це виправити try/except блоком?
🔹 Міні-кейс: Ви робите Instagram. Користувач завантажує фото.
- Producer: API, яке приймає файл.
- Consumer: Скрипт, який накладає фільтри.
- Задача: Опишіть словами або псевдокодом, що має відбуватися, якщо Consumer (сервер обробки фото) раптово вимкнувся світло. Чи має фото зникнути назавжди? (Підказка: Persistent Queue).

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

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

❌ Типові помилки новачка:

Безкінечні цикли без гальм: Consumer крутиться в while True і спалює 100% CPU, перевіряючи пусту чергу. (Треба використовувати блокуючий get() або спати).
Втрата даних: Взяв задачу з черги, крашнувся, не зберіг результат. Задача зникла. (Треба підтверджувати виконання ack тільки після успішної роботи).

🧠 Як думає Senior:

"А що, якщо черга переповниться?" У реальному світі черга не безкінечна (пам'ять закінчиться). Профі налаштовують ліміти і стратегію відмови (Backpressure) — "Вибачте, ми перевантажені, спробуйте пізніше".
"Idempotency" (Ідемпотентність): Страшне слово, проста суть. Якщо через збій мережі Consumer отримав одну й ту ж задачу двічі (наприклад, "Списати гроші"), він має бути достатньо розумним, щоб не списати гроші два рази.

6. 🧩 Підсумок

Отже, що ми сьогодні зробили? 1. Зрозуміли, що Producer створює, Consumer споживає, а Queue згладжує нерівності. 2. Дізналися, що це дозволяє системам працювати асинхронно (не блокуючи користувача). 3. Навчилися масштабувати: багато замовлень? Просто додайте більше Consumers (кухарів), не чіпаючи Producers.

Тепер ви вмієте: Проектувати логіку фонових задач. Це фундамент для надсилання пошти, обробки платежів та генерації звітів.

🔜 Далі в курсі: Ми працювали з чергою в пам'яті однієї програми. Але що, якщо Producer — це сервер у Києві, а Consumer — у Львові? На наступному уроці ми познайомимось із "дорослими" брокерами повідомлень: RabbitMQ та Kafka.

А поки що — це був CS50. Щасти! 👋