Ось готовий урок на тему "Реплікація Redis", написаний у стилі CS50: енергійно, з прикладами та фокусом на розумінні суті.

🎓 CS50: Реплікація Redis (Scaling & Safety)

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

Сьогодні ми поговоримо про те, що відрізняє "іграшковий" проект від серйозної архітектури, яка обслуговує мільйони користувачів. Ми вже знаємо, що Redis — це неймовірно швидка база даних в пам'яті. Це наш Ferrari. 🏎️

Але уявіть собі ситуацію...

1. 🔥 Вступ: Коли одного Ferrari замало

Уявіть, що ви відкрили найпопулярнішу кав'ярню в Києві. У вас є один бариста-суперзірка (назвемо його Master). Він приймає замовлення, готує каву і видає її. Все працює ідеально, поки черга маленька.

Але раптом трапляється дві речі: 1. Наплив клієнтів: Приходить 1000 людей одночасно. Вони не хочуть замовляти, вони просто запитують: "А яке у вас сьогодні меню?" або "Скільки коштує лате?". Ваш бариста не встигає варити каву, бо постійно відповідає на питання. 2. Форс-мажор: Бариста послизнувся і випав з процесу на 5 хвилин. Кав'ярня зупинилася. Бізнес втрачає гроші. Паніка! 😱

Питання до вас: Чи варто наймати другого такого ж дорогого баристу, який буде робити все? Чи, можливо, є хитріший спосіб?

У світі баз даних ми не хочемо втратити дані, якщо сервер впаде. І ми не хочемо, щоб сервер "захлинувся" від запитів на читання.

Ось тут на сцену виходить Реплікація. Це спосіб клонувати нашого баристу.

2. 🧠 Теоретична база: Як це працює "під капотом"

Давайте розберемося без складних термінів.

У Redis реплікація працює за схемою Leader-Follower (або Master-Replica).

Master (Майстер/Лідер): Це головний вузол. Тільки він може записувати нові дані (SET, DEL, HSET). У нашій аналогії — це Шеф-кухар, який затверджує нові страви в меню.
Replica (Репліка/Фоловер): Це копія майстра. Репліки зазвичай працюють тільки на читання (GET). Вони постійно "слухають" майстра і повторюють все, що він робить.

⚙️ Механіка процесу (Інтуїтивно)

Як Репліка дізнається про зміни? Вона не читає думки. Це схоже на пряму трансляцію:

Крок 1 (Синхронізація): Коли репліка підключається вперше, Майстер робить "знімок" (RDB файл) всього, що має, і кидає його Репліці. "Ось, вивчи це напам'ять!".
Крок 2 (Потік команд): Після цього, кожну команду запису (наприклад, SET user:1 "Alex"), яку отримує Майстер, він асинхронно пересилає Репліці. "Я щойно додав користувача, ти теж додай!".

☝️ Що треба запам'ятати залізно: За замовчуванням Redis використовує асинхронну реплікацію. Це означає, що Майстер каже клієнту "ОК, я записав", не чекаючи, поки Репліка підтвердить, що вона теж записала. Чому це важливо? Це дає шалену швидкість, але є мікроскопічний ризик втрати даних, якщо Майстер вимкнеться за мілісекунду до передачі даних Репліці.

3. 🧪 Приклади: Від простого до реального

Зараз ми перетворимо ваш комп'ютер на міні-кластер. Відкрийте два вікна терміналу.

Сцена 1: Запуск Майстра

В першому вікні запускаємо звичайний Redis на стандартному порту 6379.

redis-server --port 6379

Це наш Шеф-кухар.

Сцена 2: Запуск Репліки

В другому вікні запускаємо інший Redis на порту 6380 і кажемо йому: "Твій бос — це хлопець на порту 6379".

redis-server --port 6380 --replicaof 127.0.0.1 6379

(У старих версіях команда була slaveof, але replicaof — сучасний стандарт).

Подивіться в логи у другому вікні! Ви побачите щось на кшталт: MASTER <-> REPLICA sync: Receiving ... Це означає, що Репліка отримала "підручник" і готова працювати.

Сцена 3: Перевірка магії

Давайте підключимося до Майстра (порт 6379) і щось запишемо.

# Термінал 3 (Клієнт Майстра)
redis-cli -p 6379
127.0.0.1:6379> SET course "CS50"
OK

Питання до вас: Що станеться, якщо я зараз спробую прочитати ключ course з Репліки (порт 6380)?

Давайте перевіримо:

# Термінал 4 (Клієнт Репліки)
redis-cli -p 6380
127.0.0.1:6380> GET course
"CS50"

Бум! 💥 Дані там. Ми не писали їх туди вручну. Майстер зробив це за нас.

А тепер спробуйте записати в Репліку:

127.0.0.1:6380> SET myname "David"
(error) READONLY You can't write against a read only replica.

Репліка каже: "Вибач, я тільки читаю меню, змінює його Шеф".

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

Час забруднити руки кодом! Виконайте ці завдання, щоб відчути систему.

🔹 Завдання 1: Ручне налаштування Запустіть два інстанси Redis (як у прикладі вище). Запишіть 5 різних ключів на Майстер. Переконайтеся, що всі вони з'явилися на Репліці.

🔹 Завдання 2: "Вбивство" Майстра Зупиніть процес Майстра (Ctrl+C у його вікні). Спробуйте прочитати дані з Репліки. Питання: Чи зникли дані? Чи працює Репліка? (Спойлер: Репліка має віддавати старі дані, вона не вмирає разом з босом).

🔹 Завдання 3: Зміна ролей на льоту Майстер "мертвий". Зробіть Репліку новим Майстром. Зайдіть в CLI репліки (redis-cli -p 6380) і введіть команду:

REPLICAOF NO ONE

Спробуйте тепер записати дані в колишню репліку. Чи вийшло?

🔹 Завдання 4: Міні-кейс "Катастрофа" Уявіть, що ви випадково ввели команду FLUSHALL (видалити все) на Майстрі. Питання: Що станеться на Репліці? Експеримент: Перевірте це. Чи є Реплікація бекапом від людської дурості? (Відповідь вас може засмутити).

🔹 Завдання 5: Шпигунські ігри Використовуйте команду MONITOR на Репліці, поки записуєте дані на Майстер. Подивіться, як команди прилітають у реальному часі.

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

Як досвідчені інженери використовують ці знання?

Read vs Write Scalability:
- Новачок думає: "Мені потрібен потужніший сервер, бо сайт гальмує".
- Профі думає: "Подивимось метрики. Ага, у нас 90% операцій — це читання (GET), і тільки 10% — запис. Я додам 3 репліки і розподілю читання між ними. Майстер розвантажиться".
Реплікація ≠ Бекап:
- Це класична помилка. Якщо ви видалите дані на Майстрі, репліка миттєво скопіює команду "видалити". Для бекапів використовують RDB-снепшоти або AOF-файли, які зберігають окремо (наприклад, на S3).
Асинхронність:
- Пам'ятайте про "Eventual Consistency" (узгодженість у кінцевому рахунку). Дані на репліці можуть з'явитися із затримкою в кілька мілісекунд. У фінансових системах це може бути критично, але для лічильника лайків в Instagram — нікому не важливо, якщо лайк з'явиться на секунду пізніше.

6. 🧩 Підсумок

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

Масштабування: Ми можемо обробляти в рази більше запитів на читання, додаючи Репліки.
Відмовостійкість (Failover): Якщо Майстер впаде, дані залишаться на Репліці (і ми можемо підвищити її до Майстра).
Механіка: Дані течуть від Майстра до Репліки. Репліка за замовчуванням — Read-only.

Тепер ви вмієте створювати кластер, який не просто зберігає дані, а й вміє їх розмножувати для надійності!

🕵️ Тизер наступного уроку: Але чекайте... Якщо Майстер впаде вночі, поки ви спите, хто введе команду REPLICAOF NO ONE, щоб врятувати ситуацію? Ви ж не будете сидіти біля монітора 24/7? На наступному уроці ми познайомимося з Redis Sentinel — спеціальним "вартовим", який автоматично помітить аварію і перемикне рубильник за вас.

Це був CS50. Побачимось! 👋