Модуль 39

Архітектура реального проєкту з Redis

Ось готовий урок, створений за твоїм майстер-промптом. Вмикаємо режим David Malan! 🎙️

🎓 Урок: Архітектура реального проєкту з Redis

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

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

1. 🔥 Вступ: Коли база даних каже «Досить!»

Уявіть ситуацію. Ви запустили свій стартап — інтернет-магазин кросівок. Все чудово, у вас 100 користувачів на день. Ваша база даних (PostgreSQL або MySQL) почувається прекрасно. Вона як бібліотекар, який спокійно шукає потрібну книгу на полиці.

Але настає Чорна п'ятниця.

Замість 100 людей до вас заходить 100 000 одночасно. Кожен оновлює сторінку товару, щоб побачити ціну. Ваш "бібліотекар" (база даних) починає панікувати. Він бігає між полицями, пітніє, спотикається. Черга росте. Сайт починає "висіти". Користувачі бачать білий екран і йдуть до конкурентів.

Чому це сталося? Тому що бази даних зберігають інформацію на жорсткому диску (HDD/SSD). Це надійно, але це повільно порівняно з процесором.

Аналогія: Уявіть, що ви — шеф-кухар (це ваш код). * Жорсткий диск (База даних) — це комора в підвалі. Щоб взяти сіль, вам треба спуститися сходами, знайти банку і повернутися. Це довго. * Оперативна пам'ять (RAM) — це ваш робочий стіл прямо перед вами. Сіль стоїть на відстані витягнутої руки. Це миттєво.

Redis — це і є той самий робочий стіл. Це спосіб тримати найважливіші дані "під рукою", щоб не бігати в підвал за кожним дріб'язком.

Без цього знання ви не зможете побудувати жодну високонавантажену систему (Twitter, Instagram, Uber — всі вони живі завдяки подібним технологіям).

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

Давайте розберемося без зайвої академічності.

Redis (Remote Dictionary Server) — це, по суті, гігантська хеш-таблиця (або словник/dictionary), яка живе в оперативній пам'яті.

Як це працює «під капотом»?

У класичній базі даних (SQL) дані лежать у таблицях із жорсткою структурою. Щоб їх дістати, системі треба просканувати диск. У Redis дані — це прості пари Ключ: Значення (Key: Value).

Оскільки це все в RAM (оперативці): 1. Доступ займає мікросекунди (не мілісекунди!). 2. Дані зникають, якщо вимкнути живлення (за замовчуванням, хоча це можна налаштувати).

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

  • Redis — це кеш. Він пришвидшує читання.
  • Redis — це Key-Value сховище. Думайте про нього як про величезний JSON-об'єкт.
  • Він однопотоковий. Але настільки швидкий, що це рідко стає проблемою.

Архітектурний патерн "Look-aside Cache" (Кеш збоку)

Ось як це виглядає в архітектурі 90% проектів:

  1. Клієнт запитує дані (наприклад, профіль користувача).
  2. Ваш додаток спершу йде в Redis: "Ей, у нас є дані для юзера ID:42?"
  3. ✅ Якщо ТАК (Cache Hit): Миттєво віддаємо дані. Базу даних не чіпаємо.
  4. ❌ Якщо НІ (Cache Miss):
    • Йдемо в Базу Даних (повільно).
    • Забираємо дані.
    • Записуємо їх у Redis (щоб наступного разу було швидко).
    • Віддаємо клієнту.

3. 🧪 Приклади: Від Hello World до Реальності

Уявимо, що ми пишемо код (псевдокод, схожий на Python, щоб було зрозуміло всім).

Приклад 1: Hello World (Основи)

Що ми очікуємо? Просто покласти рядок і дістати його.

# Підключення
redis = Redis(host='localhost', port=6379)

# Запис (SET)
redis.set('greeting', 'Привіт, CS50!')

# Читання (GET)
message = redis.get('greeting')

print(message) 
# Результат: "Привіт, CS50!"

Все просто. Це як записати змінну, тільки вона доступна всім сервісам вашого проекту.

Приклад 2: Реальний кейс (Кешування ціни товару)

Тепер складніше. У нас є функція, яка дістає ціну товару. Пам'ятайте про Чорну п'ятницю!

Питання до вас: Що станеться, якщо ми не знайдемо ціну в Redis?

def get_product_price(product_id):
    cache_key = f"price:{product_id}"

    # 1. Спробуємо знайти в Redis (це дуууже швидко)
    price = redis.get(cache_key)

    if price is not None:
        print("✅ Взяли з кешу!")
        return price

    # 2. Якщо в кеші пусто, йдемо в "підвал" (SQL База)
    print("⏳ Йдемо в базу даних...")
    price = database.query("SELECT price FROM products WHERE id = ?", product_id)

    # 3. ВАЖЛИВО: Зберігаємо в Redis на майбутнє!
    # Але ставимо таймер життя (TTL) на 1 годину (3600 сек), 
    # щоб ціна не застаріла навічно.
    redis.set(cache_key, price, ex=3600)

    return price

Пояснення: Перший користувач почекає (похід в БД). Наступні 10,000 користувачів отримають ціну миттєво з Redis. Ви врятували сервер від смерті!

Приклад 3: Обмеження запитів (Rate Limiting)

А що, як хтось намагається зламати ваш пароль, перебираючи варіанти? Ми можемо використовувати Redis як лічильник.

def login(user_ip):
    key = f"login_attempts:{user_ip}"

    # Збільшуємо лічильник на 1 (INCR - атомарна операція)
    attempts = redis.incr(key)

    if attempts == 1:
        # Якщо це перша спроба, ставимо таймер скидання на 10 хвилин
        redis.expire(key, 600)

    if attempts > 5:
        return "⛔ Ей, полегше! Спробуй пізніше."

    # Далі логіка перевірки пароля...

Чому це круто? Тому що Redis робить це за наносекунди. База даних захлинулася б від постійного оновлення лічильників.

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

Тепер ваша черга! Не просто читайте, а подумайте, як би ви це написали.

  1. 🔹 Базовий кеш: Напишіть (на папері або в голові) логіку функції get_user_profile(user_id), яка використовує патерн "Cache Aside".
  2. 🔹 Проблема старості: У попередньому завданні ви закешували профіль. Але користувач змінив аватарку! В кеші лишилася стара. Завдання: Де в коді оновлення профілю (update_profile) треба додати команду для Redis, щоб виправити це? (Підказка: є два шляхи — оновити кеш або просто видалити його).
  3. 🔹 TTL (Time To Live): Уявіть, що ви робите сайт новин. Новини оновлюються часто. Який час життя (TTL) ви поставите для кешу "Головна сторінка": 1 секунда, 1 година, 1 день? Обґрунтуйте.
  4. 🔹 Черга задач (List): Використовуйте команди Redis LPUSH (вставити зліва) і RPOP (забрати справа). Зімітуйте роботу принтера: один додає документи в чергу, інший забирає їх на друк.
  5. 🔹 Міні-кейс: Ви робите онлайн-гру. Треба показати "Топ-10 гравців". Рахувати це по базі даних кожного разу — вбивство сервера. Як Redis (структура Sorted Set) може допомогти зберігати рейтинг в реальному часі?
  6. 🔹 "А що, якщо...": Сервер Redis раптово перезавантажився. Що станеться з вашим інтернет-магазином? Він впаде чи просто стане повільнішим?

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

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

❌ Типова помилка новачка: Використовувати Redis як єдину базу даних для важливих речей. Приклад: Зберігати список замовлень тільки в Redis. Наслідок: Сервер перезавантажився — всі замовлення зникли. Вас звільнили.

❌ Ще одна помилка: Кешувати все підряд без TTL (часу життя). Наслідок: Пам'ять забивається сміттям, сервер падає з помилкою OOM (Out Of Memory).

✅ Як думає досвідчений архітектор: 1. Дані тимчасові? (Сесії, кеш, лічильники) -> Redis. 2. Дані критичні? (Гроші, історія покупок) -> PostgreSQL/MySQL. 3. Інвалідація кешу — це найскладніше. Легше поставити короткий TTL (наприклад, 5 хвилин), ніж писати складну логіку оновлення кешу при кожній зміні даних.

"У програмуванні є дві найскладніші проблеми: naming things (як назвати змінні), cache invalidation (коли чистити кеш) і помилки на одиницю".

6. 🧩 Підсумок

Отже, що ми маємо в сухому залишку?

  1. Швидкість: Redis — це "оперативка", це блискавично швидко.
  2. Розвантаження: Ми бережемо основну базу даних від перенавантаження.
  3. Структури: Це не просто текст, це списки, лічильники та хеш-таблиці в пам'яті.

Тепер ви вмієте: Розуміти, як Instagram показує вам лайки миттєво, і як спроектувати систему, що витримає навалу користувачів. Ви більше не боїтеся слова "Кешування".

🔜 У наступній серії: Ми навчилися зберігати дані швидко. Але що, якщо нам треба виконати важку задачу (наприклад, обробити відео або надіслати 1000 email), не змушуючи користувача чекати? Ми поговоримо про Асинхронні черги задач (Celery + Redis). Це буде магія, яка відбувається у фоні!

А поки що — це був CS50... тобто, наш урок! 😉

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