Ось твій урок у стилі CS50! 🚀

🎓 CS50: Архітектура систем з RabbitMQ

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

1. 🔥 Вступ: Коли ваш сервер «захлинається»

Уявіть ситуацію. Ви запустили крутий стартап — доставку піци дронами. Клієнт натискає кнопку «Замовити».

Ваш код починає працювати: 1. Записує замовлення в базу даних. 2. Відправляє запит на склад (перевірити наявність інгредієнтів). 3. Надсилає email-підтвердження клієнту. 4. Стукає у платіжну систему, щоб списати гроші. 5. Відправляє команду дрону на зліт.

І все це відбувається... синхронно. Послідовно. Клієнт дивиться на кружечок завантаження 5, 10, 15 секунд... І йде до конкурентів, бо «сайт висить».

А що, як платіжна система відповідає 30 секунд? А що, як сервіс дронів упав? Весь ваш сайт падає разом з ними.

Питання до вас: Чи повинен касир у McDonald’s сам бігти на кухню смажити котлету, поки ви стоїте біля каси? Звісно, ні! Касир просто кричить: «Вільна каса! Одне лате!» і приймає наступного клієнта. А каву робить бариста — тоді, коли звільниться.

Саме це ми сьогодні й вивчимо. RabbitMQ — це той самий механізм, який дозволяє вашій системі прийняти замовлення миттєво, а «смажити котлети» (обробляти дані) у фоновому режимі.

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

Давайте розберемо це на атоми. RabbitMQ — це Message Broker (брокер повідомлень).

Аналогія: Поштове відділення 📮

Уявіть RabbitMQ як поштову скриньку та сортувальний центр.

Producer (Продюсер/Виробник): Це ваш сайт. Він пише листа («Треба надіслати email клієнту») і кидает його в скриньку. Його робота зроблена. Він вільний!
Exchange (Обмінник): Це сортувальник на пошті. Він бере листа і дивиться: «Ага, це для відділу emails», або «Це для відділу логістики».
Queue (Черга): Це власне поштова скринька, де листи лежать і чекають. Це буфер.
Consumer (Консюмер/Споживач): Це поштар (або окремий мікросервіс), який забирає листа з черги і виконує роботу (насправді відправляє email).

🔑 Що треба запам’ятати залізно:

Decoupling (Розв’язка): Продюсер нічого не знає про Консюмера. Якщо сервіс відправки листів згорить, сайт продовжить працювати і приймати замовлення. Листи просто полежать у черзі, поки сервіс не полагодять.
Асинхронність: Ми не чекаємо результату одразу.

Як це працює технічно (спрощено):

Ви не кидаєте повідомлення прямо в чергу (хоча іноді так кажуть для спрощення). Ви кидаєте його в Exchange. А Exchange вирішує, у яку чергу (або черги) його покласти, використовуючи правила маршрутизації (Routing Keys).

Інтуїтивно: Продюсер — це той, хто кричить задачу. RabbitMQ — це дошка завдань. Консюмер — це працівник, який підходить до дошки і бере стікер.

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

Давайте подивимось на код. Ми використаємо бібліотеку pika (стандарт для Python).

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

Що ми очікуємо? Ми запустимо скрипт, який відправить повідомлення, і скрипт, який його отримає.

Producer (send.py):

import pika

# 1. Підключаємось до RabbitMQ (локально)
connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
channel = connection.channel()

# 2. Створюємо чергу 'hello', якщо її ще немає
channel.queue_declare(queue='hello')

# 3. Відправляємо повідомлення
channel.basic_publish(exchange='', routing_key='hello', body='Привіт, Rabbit!')
print(" [x] Відправлено 'Привіт, Rabbit!'")

connection.close()

Consumer (receive.py):

import pika

connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
channel = connection.channel()
channel.queue_declare(queue='hello')

# Функція, яка викликається, коли приходить повідомлення
def callback(ch, method, properties, body):
    print(f" [x] Отримано: {body.decode()}")

# Підписуємось на чергу
channel.basic_consume(queue='hello', auto_ack=True, on_message_callback=callback)

print(' [*] Чекаю на повідомлення. Натисніть CTRL+C для виходу')
channel.start_consuming()

Що відбулося? Ви запустили receive.py. Він завис у очікуванні. Запустили send.py — повідомлення миттєво з'явилося у першому вікні. Магія? Ні, TCP-сокети та протокол AMQP.

Приклад 2: "Worker Queues" (Реальне життя)

А тепер уявіть, що обробка займає час. Наприклад, ресайз зображень (важка задача).

Якщо ми запустимо один Producer і два Consumers, як RabbitMQ розподілить задачі?

RabbitMQ за замовчуванням використовує Round Robin. Перше повідомлення -> Робітнику А. Друге повідомлення -> Робітнику Б. Третє повідомлення -> Робітнику А.

Це дозволяє нам масштабуватися. Якщо черга росте — ми просто запускаємо ще 5 скриптів-консюмерів, і вони розгрібають завал швидше!

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

Час забруднити руки. Для виконання потрібен Docker або встановлений RabbitMQ.

Завдання 1: Запуск Запустіть код із Прикладу 1. Переконайтесь, що вони "бачать" одне одного.

Завдання 2: "Конкуренція" Запустіть receive.py у двох різних терміналах. Тепер запустіть send.py 4 рази поспіль (змінюючи текст повідомлення). Питання: Хто отримав які повідомлення? Чи отримав один консюмер усі повідомлення? (Має бути розподіл 50/50).

Завдання 3: Імітація важкої роботи Змініть код callback у консюмері. Додайте time.sleep(5). Відправте повідомлення. Вбийте (Ctrl+C) скрипт консюмера, поки він "спить" (до 5 секунд). Що сталося з повідомленням? Якщо auto_ack=True, повідомлення зникло назавжди. Це погано! Виправлення: Змініть на auto_ack=False і додайте ch.basic_ack(delivery_tag=method.delivery_tag) в кінці функції callback. Тепер, якщо консюмер помре, RabbitMQ побачить, що підтвердження не було, і віддасть задачу іншому!

Завдання 4: Міні-кейс (Логування) Напишіть систему, де Producer генерує логи ("Info: все ок", "Error: база впала"). Створіть Exchange типу fanout. Підключіть два Consumers: 1. Пише всі логи на екран. 2. Пише тільки логи у файл (умовно). (Підказка: fanout дублює повідомлення у всі підключені черги).

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

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

🚫 Помилки новачка:

Використання черги як бази даних. RabbitMQ не призначений для довгого зберігання історії. Обробив — видалив.
Забув про ACK (підтвердження). Повідомлення обробилося, але RabbitMQ про це не знає і відправляє його знову і знову. Нескінченний цикл болю.
Віра в порядок. Ви думаєте, що повідомлення обробляться строго 1, 2, 3? У розподіленій системі з багатьма консюмерами порядок не гарантується. Якщо вам критичний порядок — архітектуру треба міняти.

🧠 Як думає архітектор:

"Що, якщо RabbitMQ впаде?" Профі вмикає Durable queues (стійкі черги) і Persistent messages, щоб вони зберігалися на диск, а не тільки в RAM.
"Що робити з отруйними повідомленнями?" Якщо повідомлення викликає помилку в коді (баг), ми не можемо обробляти його вічно. Профі налаштовує Dead Letter Queue (DLQ) — цвинтар для повідомлень, які не вдалося обробити після N спроб.
Idempotency (Ідемпотентність): Страшне слово, проста суть. Якщо ваша система випадково обробить одне й те саме замовлення двічі (наприклад, зняття коштів) — клієнт буде лютувати. Профі пишуть код так, щоб повторна обробка того ж ID не робила нічого шкідливого.

6. 🧩 Підсумок

Отже, що ми маємо?

RabbitMQ — це клей, який дозволяє різним частинам вашої системи спілкуватися, не знаючи про існування одне одного.
Він дозволяє згладжувати пікові навантаження (буферизація).
Він робить систему надійною: якщо падає обробник, задачі не губляться.

Ви тепер вмієте: * Створювати прості черги. * Розподіляти навантаження між воркерами. * Розумієте різницю між "відправив і забув" та "гарантована доставка".

🍿 Тизер наступного уроку:

Сьогодні ми передавали прості текстові повідомлення. Але що, як нам треба передати цілий об'єкт користувача або складну структуру даних між Python-сервісом і Java-сервісом? На наступному уроці ми поговоримо про серіалізацію даних (JSON, Protobuf) та чому це мова есперанто для комп'ютерів.

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