Ось повноцінний урок, згенерований у стилі David Malan (CS50), адаптований для української аудиторії.

🏛 CS50: Redis Sentinel та High Availability (HA)

Або: Як зробити так, щоб ваша база даних ніколи не спала

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

Сьогодні ми не просто пишемо код. Сьогодні ми вчимося будувати системи, які неможливо вбити.

1. 🔥 Вступ: Коли все йде шкереберть

Уявіть собі, що ви створили наступний Facebook або Monobank. У вас мільйони користувачів. Чорна п’ятниця. Усі купують товари, транзакції летять зі швидкістю світла.

І раптом... БАЦ! 💥

Сервер, де крутиться ваш Redis (а там, наприклад, кошики користувачів або кеш сесій), згоряє. Просто фізично вимикається. Диск помер, кабель перегриз щур, адмін спіткнувся об дріт.

Що відбувається далі? * Сайт падає. * Кошики зникають. * Гроші не списуються (або гірше — списуються, а товару немає). * Ви втрачаєте тисячі доларів щохвилини.

Риторичне питання: Чи хотіли б ви бути тим інженером, якому дзвонять о 3-й ночі, щоб він вручну перемикав дроти й рятував бізнес? Думаю, ні.

Ми звикли, що у нас є один сервер (Master), і ми з ним працюємо. Але в реальному світі все, що може зламатися — зламається.

Сьогодні ми розберемо Redis Sentinel. Це технологія, яка перетворює вашу крихку систему на "безсмертну".

Аналогія: Уявіть кухню ресторану. * Є Шеф-кухар (Master) — тільки він вирішує, що готувати, і приймає замовлення. * Є Су-шефи (Replicas) — вони повторюють все, що робить Шеф, і віддають готові страви. * А Sentinel — це суворий менеджер залу, який стоїть збоку. Він не готує. Він дивиться на Шефа. Якщо Шеф знепритомнів, менеджер не панікує. Він кричить: "Ти, Су-шеф №1, тепер ти — Шеф! Одягай ковпак!". І робота кухні не зупиняється ні на секунду.

Ось навіщо нам це потрібно. Поїхали розбиратися! 🚀

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

Перш ніж лізти в консоль, давайте зрозуміємо логіку. Тут немає магії, тут чиста бюрократія.

Ключові гравці:

Master (Майстер): Головний вузол Redis. Тільки він приймає запис (WRITE).
Replica (Репліка/Слейв): Копія майстра. Отримує дані від майстра в реальному часі. З неї можна читати (READ), але зазвичай не можна писати.
Sentinel (Вартовий): Це окремий процес. Це не база даних! Це спеціальна програма, яка моніторить ваші Redis-сервери.

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

Уявіть, що у вас є 1 Master, 2 Replicas і 3 процеси Sentinel.

Моніторинг: Sentinel постійно пінгує Master: "Ти живий? Ти живий?".
Суб’єктивна падіння (SDOWN): Якщо один Sentinel не отримав відповідь, він думає: "Хм, здається, Майстер впав". Але це тільки його думка. Може, це у Sentinel інтернет глючить.
Об’єктивне падіння (ODOWN) та Кворум: Цей Sentinel питає інших вартових: "Ей, ви бачите Майстра?". Якщо більшість (це називається Кворум) каже "Ні, він мертвий", тоді падіння визнається офіційним.
Вибори лідера: Вартові обирають одного зі своїх, хто буде проводити операцію порятунку (Failover).
Failover (Перемикання):
- Обирається найкраща Репліка (найсвіжіші дані).
- Вона перетворюється на нового Майстра.
- Інші репліки переналаштовуються на нового боса.
- Коли старий Майстер "оживе", він автоматично стане реплікою (його понизять у посаді).

👉 Що треба запам’ятати залізно: Ваша програма більше не повинна підключатися до Redis напряму за IP-адресою Майстра. Вона має питати у Sentinel: "Хто зараз головний?".

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

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

Мінімальний `sentinel.conf`

Ви очікуєте там тисячі рядків? Ні, все набагато простіше.

port 26379
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000

Розберемо по кісточках: * monitor mymaster 127.0.0.1 6379 2: * mymaster — ім'я групи серверів. * IP та порт поточного Майстра. * 2 — це Кворум. Це означає, що як мінімум 2 Sentinel-процеси мають погодитися, що Майстер впав, щоб почати паніку. * down-after-milliseconds 5000: Якщо Майстер мовчить 5 секунд — вважаємо його мертвим.

Сценарій з реального життя

Уявіть Python-код (спрощено), як ми зазвичай підключаємось:

# ❌ ПОГАНО (для HA)
r = redis.Redis(host='192.168.1.5', port=6379)

Чому це погано? Якщо 192.168.1.5 згорить, ваш код буде стукати в зачинені двері.

# ✅ ДОБРЕ (Sentinel)
from redis.sentinel import Sentinel

sentinel = Sentinel([('192.168.1.10', 26379),
                     ('192.168.1.11', 26379),
                     ('192.168.1.12', 26379)], socket_timeout=0.1)

# Ми просимо Sentinel дати нам правильного майстра
master = sentinel.master_for('mymaster', socket_timeout=0.1)
master.set('foo', 'bar')

Що тут відбулося? Ми дали бібліотеці список Sentinel-ів. Бібліотека сама спитає: "Гей, хто зараз бос?". Sentinel відповість IP-адресою поточного лідера. Якщо лідер зміниться, бібліотека дізнається про це автоматично. Геніально, правда?

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

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

Завдання 1: Запуск "Оркестру" Уявіть, що ви запустили: * 1 Redis Master (порт 6379) * 2 Redis Replicas (порти 6380, 6381) * 3 Sentinel процеси (порти 26379, 26380, 26381)

Завдання 2: Перевірка статусу Підключіться до будь-якого Sentinel: redis-cli -p 26379 Введіть команду: SENTINEL get-master-addr-by-name mymaster Що ви очікуєте побачити? (Правильно, IP та порт 6379).

Завдання 3: Вбивство! (Simulation) Знайдіть PID процесу Майстра і вбийте його (kill -9 <PID>) або зупиніть контейнер. Зачекайте 5-10 секунд (час, який ми вказали в конфізі).

Завдання 4: Спостереження за магією Знову введіть у Sentinel: SENTINEL get-master-addr-by-name mymaster. Результат: Порт змінився! Наприклад, на 6380. Sentinel автоматично перепризначив лідера.

Завдання 5: Повернення блудного сина Запустіть старий Майстер (6379) знову. Перевірте його роль (INFO replication). Питання: Він знову став Майстром? Відповідь: Ні! Він став реплікою нового Майстра (6380). Система самовідновилася.

Завдання 6 (Мисленнєвий експеримент): А що буде, якщо у вас всього 2 Sentinel-и, і ви поставите кворум 2? Ситуація: Мережа між ними розірвалася. Результат: Жоден з них не зможе зібрати кворум (потрібно 2 голоси, а кожен бачить тільки себе). Failover не відбудеться. Система заблокується. Тому Sentinel-ів завжди має бути непарна кількість (3, 5...).

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

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

❌ Новачок: 1. Використовує Sentinel, але в коді прописує IP-адресу конкретного Redis-сервера. (Sentinel працює, сервер перемикається, а додаток все одно лежить, бо довбається в стару IP). 2. Ставить Sentinel на ту саму фізичну машину, що і Redis. (Якщо машина згорить, згорить і "охоронець", і "шеф". Хто тоді натисне кнопку тривоги?).

✅ Досвідчений інженер: 1. Thinking in Failure Modes: "Що, якщо мережа впаде? Що, якщо Sentinel зависне?". Він знає про "Split Brain" (роздвоєння свідомості кластера) і налаштовує кворуми правильно. 2. Тестує Failover: Він не чекає аварії. Він спеціально "вбиває" сервери на тестовому середовищі, щоб переконатися, що додаток перепідключається коректно. 3. Клієнтська бібліотека: Він перевіряє, чи вміє драйвер його мови програмування (Go, Node, PHP) працювати з Sentinel. Не всі драйвери це вміють "з коробки"!

6. 🧩 Підсумок

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

Один Redis — це точка відмови. Це ризик.
Redis Sentinel — це система моніторингу та автоматичного перемикання (Failover).
Sentinel-и працюють командою (кворум), щоб уникнути помилкових тривог.
Ваш код має спілкуватися з Sentinel, а не напряму з Redis.

Тепер ви вмієте будувати архітектуру, яка витримує удари долі. Ви спите спокійно, поки Sentinel охороняє ваші дані.

🤔 Тизер наступного уроку: Ми зробили систему надійною. Але що, якщо даних стане ТАК багато, що вони не влізуть в пам’ять одного сервера? Навіть найнадійнішого? На наступному уроці ми поговоримо про Redis Cluster та Sharding (шардінг). Як розрізати базу даних на шматочки, щоб вона була не тільки безсмертною, а й нескінченною.

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