Ось твій урок у стилі David Malan (CS50). Запалюємо! 🔥

🎓 CS50: Redis Persistence (RDB & AOF)

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

1. 🔥 Вступ: Кошмар системного адміністратора

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

І тут... БЛИМ! ⚡️

У дата-центрі вимикається світло. Або прибиральниця випадково висмикнула кабель сервера. Або просто kernel panic. Сервер перезавантажується.

Питання на мільйон: Що сталося з тисячами кошиків ваших покупців, які були в оперативній пам'яті?

Правильно. Вони зникли. Пусто. Null. 💨 Оперативна пам'ять — вона як ваша короткочасна пам'ять: пам'ятає, поки ви не заснете. Як тільки живлення зникає — дані випаровуються.

Для бізнесу це катастрофа. Втрачені гроші, розлючені клієнти. Саме тому нам потрібна Persistence (Персистентність) — здатність даних "виживати" після перезавантаження.

Сьогодні ми розберемо два головні механізми, як змусити Redis не забувати: RDB та AOF.

2. 🧠 Теоретична база: Фотоапарат vs Журналіст

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

У Redis є два шляхи:

📸 Шлях 1: RDB (Redis Database) — "Знімок"

Це як дістати смартфон і зробити фотографію дошки раз на годину. * Як це працює: Redis створює компактний бінарний файл (наприклад, dump.rdb), який є точною копією пам'яті в конкретний момент часу. * Логіка: "Збережи все, що є зараз, і забудь про минуле". * Плюс: Дуже швидко відновлюватися (просто завантажити фотку в пам'ять). * Мінус: Якщо світло зникло через 59 хвилин після останнього фото, ви втратили 59 хвилин роботи.

📝 Шлях 2: AOF (Append Only File) — "Журнал подій"

Це як посадити в кутку стенографіста, який записує кожну вашу дію. * "Викладач написав X = 5" * "Викладач стер Y" * "Викладач додав Z" * Як це працює: Кожна команда зміни даних (SET, INCR, DEL) дописується в кінець текстового файлу. * Плюс: Ви майже нічого не втрачаєте (максимум — останню секунду). * Мінус: Файл може стати гігантським. Щоб відновитися, Redis мусить "програти" цей журнал з початку, що довше, ніж просто завантажити знімок.

❗️ Запам'ятайте головне: * RDB = Періодичні бекапи (швидко, але ризиковано). * AOF = Надійність (безпечно, але повільніше).

3. 🧪 Приклади: Від теорії до `redis.conf`

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

Приклад 1: Налаштування RDB (Знімки)

Відкриваємо конфіг redis.conf. Що ми там шукаємо? Директиву save.

# Формат: save <секунди> <кількість змін>

save 900 1
save 300 10
save 60 10000

Що тут відбувається? Це тригери. Redis зробить знімок, якщо: 1. Минуло 900 сек (15 хв) І змінився хоча б 1 ключ. 2. Минуло 300 сек (5 хв) І змінилося 10 ключів. 3. Минуло 60 сек І змінилося 10 000 ключів.

Питання до вас: Чому для 10 000 ключів час всього 60 секунд? (Пауза для роздумів) Відповідь: Тому що якщо даних змінюється багато, ризик втрати зростає, тому ми хочемо зберігати частіше!

Приклад 2: Налаштування AOF (Журнал)

Щоб увімкнути надійний режим:

appendonly yes
appendfsync everysec

Що таке appendfsync? Це частота запису на диск. * always — параноїдальний режим. Запис після кожної команди. Повільно, як равлик. * everysec — золота середина. Запис раз на секунду. Якщо краш — втрачаємо 1 секунду даних. * no — нехай операційна система сама вирішує, коли писати. Швидко, але небезпечно.

Приклад 3: Що всередині файлу AOF?

Давайте глянемо в файл .aof. Це не магія, це текст (протокол RESP):

*2     <- масив з 2 елементів
$6     <- довжина наступного рядка (6 байт)
SELECT
$1     <- довжина наступного рядка
0
*3
$3
set
$4
name
$5
David

Це буквально означає: SELECT 0, потім SET name David. Redis просто перечитує це при старті.

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

Час забруднити руки. У вас має бути встановлений Redis (локально або в Docker).

Завдання 1: Тест на виживання (RDB) 1. Запустіть Redis. Перевірте, що в конфізі є save 60 1. 2. Створіть ключ: SET survival "I will survive". 3. Зачекайте 60 секунд (або виконайте команду SAVE вручну). 4. Вбийте процес Redis (kill -9 <pid> або зупиніть контейнер). 5. Запустіть знову. 6. Зробіть GET survival. Дані на місці? Чудово.

Завдання 2: "Ой, я видалив базу" (Магія AOF) 1. Увімкніть AOF (appendonly yes). 2. Наповніть базу даними: SET user:1 "Alex", SET user:2 "Maria". 3. Випадково (нібито) виконайте команду FLUSHALL. Всі дані зникли! 😱 4. Зупиніть Redis. 5. Хакерська задача: Відкрийте файл appendonly.aof у текстовому редакторі. 6. Знайдіть в кінці команду FLUSHALL і видаліть її. Збережіть файл. 7. Запустіть Redis. 8. Перевірте ключі. Чи повернулися Алекс і Марія?

Завдання 3: Питання "А що, якщо..." Уявіть, що ви зробили INCR counter 1 мільйон разів. В AOF файлі буде 1 мільйон записів: INCR, INCR, INCR... Але реальне значення просто 1000000. Навіщо нам зберігати історію змін? Завдання: Знайдіть команду, яка "стискає" AOF файл, перетворюючи історію на фінальний результат. (Підказка: шукайте BGREWRITEAOF).

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

Як думають профі, коли налаштовують Redis?

Не існує "безкоштовного" збереження. RDB навантажує процесор (бо треба зробити fork процесу і скинути пам'ять). AOF навантажує диск (постійний запис). Вибирайте інструмент під задачу.
Типова помилка новачка: Використовувати Redis як єдине джерело істини для критичних даних (наприклад, транзакцій), не розуміючи налаштувань. Порада: Якщо дані супер-критичні, можливо, їм місце в PostgreSQL, а Redis — лише кеш.
Гібридний підхід — стандарт індустрії. У більшості випадків ми вмикаємо і RDB, і AOF. RDB дає компактні бекапи для Disaster Recovery (відправити бекап на AWS S3). AOF гарантує цілісність даних при перезавантаженні.
Моніторинг. Досвідчений інженер завжди дивиться на метрику rdb_last_bgsave_status та aof_last_write_status. Якщо диск забився, Redis перестане записувати дані і програма "впаде". Слідкуйте за місцем на диску!

6. 🧩 Підсумок

Сьогодні ви дізналися, як не втратити дані, коли світ летить шкереберть:

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

Тепер ви не просто "користувач Redis", ви — інженер, який вміє будувати надійні системи.

🔜 У наступній серії: Ми навчилися зберігати дані на одному комп'ютері. Але що, якщо він згорить фізично? Або навантаження стане таким, що один сервер не впорається? Наступного разу ми поговоримо про Реплікацію (Replication) та Кластеризацію.

А поки — практикуйтеся і не забувайте робити бекапи! Побачимось! 👋