Модуль 13

Idempotent tasks та повторне виконання

Ось готовий урок, створений за твоїм майстер-промптом.

🎓 CS50-style: Idempotent Tasks та Повторне виконання

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

Сьогодні ми поговоримо про річ, яка відділяє "просто працюючий код" від надійних, "бронебійних" систем, які витримують хаос реального світу. Ми говоритимемо про Ідемпотентність (Idempotency).

Звучить як складний математичний термін, правда? Але не лякайтеся. До кінця цього уроку ви будете використовувати це слово так само впевнено, як "змінна" чи "функція".

Поїхали! 🚀

1. 🔥 Вступ: Кошмар подвійної оплати

Уявіть ситуацію. Ви купуєте квиток на довгоочікуваний концерт. Ціна питання — 3000 гривень. Ви вводите дані картки, натискаєте кнопку "Оплатити"... і тут Wi-Fi глючить.

Крутиться колесо завантаження. 🔄 Нічого не відбувається. Ви чекаєте 10 секунд. Нервуєте. І що ви робите? Правильно, ви натискаєте "Оплатити" ще раз!

Питання: Скільки грошей має списатися з вашої картки? Звісно, 3000 грн.

Але якщо програміст не знав про тему нашого уроку, з вас спишуть 6000 грн. Чому? Тому що перший запит міг дійти до сервера, але відповідь до вас не повернулася через збій мережі. Ви відправили другий — і сервер чесно обробив його знову.

Навіщо нам ідемпотентність? В ідеальному світі інтернет працює безперебійно, сервери ніколи не падають, а користувачі ніколи не клікають двічі. Але ми живемо в реальному світі. * Мережа зникає. * Сервіси "таймаутять". * Черги повідомлень (Message Queues) доставляють повідомлення по кілька разів.

Без ідемпотентності ваша система — це картковий будиночок. З нею — це фортеця.

2. 🧠 Теоретична база: Що це і як працює?

Давайте дамо визначення, але без нудної академічності.

Ідемпотентність — це властивість операції, яка дає той самий результат, скільки б разів ви її не виконували.

Математична аналогія:

  • $f(x) = x \times 1$ — ідемпотентна (множення на 1 нічого не змінює, хоч сто разів помнож).
  • $f(x) = |x|$ (модуль числа) — ідемпотентна (модуль від модуля - те саме).
  • $f(x) = x + 1$ — НЕ ідемпотентна (кожен виклик змінює результат).

У розробці ПЗ:

Головне, що ви маєте зрозуміти: Побічний ефект (side effect) має статися лише один раз.

Як це працює "під капотом"? (Механіка Idempotency Key)

Уявіть, що ви приходите на пошту відправити посилку. 1. Ви даєте посилку. 2. Працівник клеїть на неї унікальний штрих-код (наприклад, ID-123). 3. Якщо ви через 5 хвилин прийдете з тією ж посилкою і тим же штрих-кодом ID-123, працівник скаже: "Ей, друже, ця посилка вже в системі, я не буду відправляти її вдруге".

Логіка сервера: 1. Клієнт генерує унікальний ключ (UUID) — Idempotency Key. 2. Клієнт надсилає запит: "Спиши 100 грн, ключ операції abc-888". 3. Сервер перевіряє базу даних: "Чи бачив я ключ abc-888?" * Ні: Виконує операцію, зберігає результат і ключ. * Так: Не виконує операцію, а просто віддає збережений результат першої спроби.

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

Приклад 1: Лампочка 💡

Уявіть, що у вас є API для розумного будинку.

  • Варіант А (Погано): Функція toggleLight().
    • Натиснули раз: світло увімкнулось.
    • Мережа глюкнула, ретрай (повтор): світло вимкнулось.
    • Результат: Непередбачуваний.
  • Варіант Б (Ідемпотентно): Функція setLight(state="ON").
    • Натиснули раз: світло увімкнулось.
    • Повтор: світло все ще увімкнене.
    • Результат: Стабільний.

Приклад 2: Платіжна система (код) 💳

Давайте подивимось на псевдокод. Що ви очікуєте побачити тут як захист?

# Вхідні дані: user_id, amount, idempotency_key

def process_payment(user_id, amount, idempotency_key):
    # 1. Перевірка: чи ми вже робили це?
    existing_transaction = db.find_transaction(key=idempotency_key)

    if existing_transaction:
        print("Це повторний запит! Повертаємо старий чек.")
        return existing_transaction.status

    # 2. Якщо ні - виконуємо логіку
    new_transaction = bank.charge(user_id, amount)

    # 3. Зберігаємо результат разом з ключем!
    db.save_transaction(data=new_transaction, key=idempotency_key)

    return new_transaction.status

Чому це круто? Якщо ваш додаток на телефоні через поганий 4G надішле цей запит тричі, банківський рахунок користувача постраждає лише один раз.

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

А тепер ваша черга! Спробуйте вирішити ці кейси.

Завдання 1: Визначте, що є ідемпотентним (Так/Ні) 1. HTTP GET запит (отримати список товарів). 2. SQL запит: UPDATE users SET status = 'active' WHERE id = 5; 3. SQL запит: UPDATE users SET visits = visits + 1 WHERE id = 5; 4. Видалення файлу delete file.txt (якщо файл вже видалений, помилка не повертається, просто "ок").

Завдання 2: Дизайн API Ви робите API для замовлення піци POST /order. Де клієнт має передавати Idempotency-Key? * А) В URL (/order?key=123) * Б) В тілі JSON ({ "pizza": "Pepperoni", "key": "123" }) * В) В HTTP заголовку (Header: Idempotency-Key: 123) (Подумайте, як це роблять Stripe або PayPal).

Завдання 3: Міні-кейс "Черга повідомлень" Ви використовуєте RabbitMQ. У вас є воркер (worker), який відправляє email "Ласкаво просимо". Іноді воркер падає після відправки email, але до того, як повідомити чергу, що завдання виконано. Черга думає, що завдання провалено, і віддає його іншому воркеру. Результат: Користувач отримує 2 листи. Питання: Як виправити це, використовуючи базу даних?

Завдання 4: А що, якщо... Що робити, якщо прийшов запит з тим самим Idempotency-Key, але тіло запиту інше? (Наприклад, ключ той самий, але сума платежу змінилася з 100 на 200). Це хакер? Це помилка? Як має відповісти сервер?

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

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

  1. Наївний підхід: "Я просто перевірю, чи є такий запис у базі".

    • Проблема: Race Condition (стан гонитви). Якщо два запити прилетять одночасно (в ту саму мілісекунду), обидва можуть прочитати, що запису немає, і обидва створять дубль.
    • Рішення профі: Використовувати Unique Constraint у базі даних на колонку idempotency_key. База даних сама викине помилку другому запиту. Це найнадійніший запобіжник.

  2. Помилка ретраїв:

    • Новачки часто думають: "Якщо помилка — треба повторити".
    • Досвідчений розробник знає: Повторювати треба тільки мережеві помилки (500, Timeout). Якщо сервер відповів "400 Bad Request" (невірні дані), повторювати той самий запит безглуздо.

  3. Порада:

    • У розподілених системах є правило: ви можете гарантувати доставку повідомлення "At least once" (хоча б раз). Гарантувати "Exactly once" (рівно один раз) на рівні мережі майже неможливо.
    • Тому ми будуємо систему так: мережа доставляє "хоча б раз" (може бути дубль), а наш код (через ідемпотентність) фільтрує дублі, перетворюючи це на "рівно один раз".

6. 🧩 Підсумок

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

  1. Ідемпотентність — це коли $1 + 0 = 1$, скільки б разів ми не додавали нуль. Повторне виконання не ламає систему.
  2. Це критично важливо для платежів, замовлень та роботи з поганим інтернетом.
  3. Головний інструмент — Idempotency Key та перевірка його унікальності в базі даних.

Тепер ви вмієте проєктувати API, які не бояться подвійних кліків і падіння Wi-Fi. Ваші користувачі (і їхні гаманці) скажуть вам "дякую".

Що далі? У наступному уроці ми поговоримо про те, що робити, коли два користувачі намагаються забронювати останнє місце в літаку одночасно. Готуйтесь, будемо розбирати Блокування (Locks) та Транзакції! 🔒

А поки — спробуйте не натискати кнопку ліфта двічі. Це все одно не допоможе йому приїхати швидше! 😉

Успіхів у коді!

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