Redis — кешування в пам'яті для сайтів і магазинів
Redis — це шар швидкості за сайтами, магазинами й маркетплейсами, збудованими на 4buildsite: він тримає в пам'яті (RAM) саме ті дані, які часто читаються, — кешовані сторінки, сесії, кошики, ліміти частоти запитів — і віддає їх без звернення до диска. Джерелом істини залишається PostgreSQL; Redis захищає її при високому трафіку і знижує навантаження на неї. Він входить у платформу й обслуговується нею, без жодного налаштування з вашого боку.
Що таке Redis і як він працює
Redis (REmote DIctionary Server) — це база даних у пам'яті з відкритим кодом: тримає дані в RAM, а не на диску. На 4buildsite ми використовуємо її як шар прискорення перед PostgreSQL — для всього, що часто читається: сторінок, сесій, кошиків і лімітів частоти запитів.
На відміну від диска, RAM на порядки швидша, а Redis додає нативні структури даних (string, hash, list, set, sorted set, stream), що дозволяють складні операції безпосередньо в пам'яті, без поїздки туди й назад до основної бази. Обробка команд однопотокова, тому поведінка передбачувана й без race conditions.
- Типова затримка менш ніж 1 мс і понад 100 000 операцій на секунду на одному вузлі
- Нативні структури: hash для сесій, sorted set для топів і обмеження частоти запитів, stream для черг
- Однопотокова обробка команд → передбачувана поведінка, без складних блокувань
Кешування: ваші сторінки й дані, віддані з пам'яті
Стратегія — cache-aside: перший запит читає з PostgreSQL і зберігає результат у Redis із TTL (часом життя); наступні запити беруть його безпосередньо з пам'яті. Коли ви редагуєте сторінку, ключ явно видаляється — ми ніколи не віддаємо застарілі дані через сліпий TTL.
Для сайту-візитки чи магазину це означає, що списки товарів, меню, популярні сторінки та фрагменти контенту віддаються з пам'яті, не перевантажуючи базу даних. У піки (кампанія, Black Friday) Redis поглинає повторювані запити, а основна база отримує менше звернень.
- Cache-aside з явною інвалідацією — без застарілих даних
- Зберігає фрагменти сторінок і результати запитів, а не лише сторінки цілком
- Захищає PostgreSQL у піки трафіку
Сесії, кошик і захист від зловживань
Сесії користувачів і refresh-токени зберігаються в Redis: автентифікація, автоматичне завершення через TTL і відкликання на всіх пристроях, коли хтось виходить із системи або змінює пароль.
Кошик у магазинах, збудованих на 4buildsite, для неавтентифікованих відвідувачів тримається в Redis — із завершенням терміну дії, не роздуваючи основну базу. Redis також застосовує обмеження частоти запитів до форм зворотного зв'язку та входу за допомогою sorted sets, щоб зупиняти спам і спроби підбору пароля ще до того, як вони досягнуть бази даних.
- Сховище сесій з автоматичним завершенням і вибірковим відкликанням токенів
- Постійний кошик із TTL для анонімних відвідувачів
- Обмеження частоти запитів і захист від зловживань на формах та автентифікації
Реальний час і черги фонових завдань
Redis Pub/Sub і Streams забезпечують оновлення в реальному часі: залишок, що зменшується наживо, сповіщення в застосунку, зміна статусу замовлення — і все без того, щоб відвідувач оновлював сторінку, і без повторюваного опитування, що виснажує сервер.
Важкі завдання (обробка зображення, генерація експорту, синхронізація) потрапляють у чергу Redis і виконуються воркерами у фоні, щоб відвідувач не чекав на їх завершення. Механізм розподіленого блокування гарантує, що критична операція не виконається двічі.
- Pub/Sub і Streams для подій наживо (залишки, замовлення, сповіщення)
- Черги завдань для важких обробок, що виконуються асинхронно
- Розподілене блокування для операцій, які не повинні виконуватися двічі
Переваги та обмеження
Переваги
- Кешовані дані читаються з пам'яті
- Різко знижує навантаження на PostgreSQL за високого трафіку
- Нативні структури для сесій, кошика, обмеження частоти запитів і топів
- Pub/Sub і Streams для функцій реального часу без опитування
- Черги завдань для важких обробок без блокування відвідувача
- Входить у платформу й обслуговується нею — нуль налаштувань для вас
Обмеження
- Дані зберігаються в RAM, яка дорожча за диск → не підходить для величезних обсягів «холодних» даних
- Це кеш / допоміжний шар, а не джерело істини — постійні дані залишаються в PostgreSQL
- Персистентність (RDB/AOF) зменшує, але не усуває повністю ризик втратити останні секунди при збої
- Потребує правильної стратегії інвалідації, інакше може віддавати застарілі дані
Короткий висновок
Використовуйте Redis для всього, що часто читається, — кешування, сесій, кошика, обмеження частоти запитів, реального часу та черг завдань. Не використовуйте його як основне сховище даних; для цього залишається PostgreSQL. На 4buildsite ви маєте обидві, підібрані автоматично: не потрібно обирати чи щось налаштовувати.
Таблиця специфікацій
| Можливість | Деталі | Де використовується в білдері |
|---|---|---|
| Затримка | < 1 мс (у пам'яті) | Сторінки й дані віддаються з пам'яті |
| Пропускна здатність | > 100 000 оп/с на вузол | Високий трафік, менше навантаження на базу |
| Структури даних | string, hash, list, set, sorted set, stream | Сесії, кошик, топи, черги, обмеження частоти запитів |
| Персистентність | Знімок RDB + журнал AOF | Відновлення після перезапуску (RDB/AOF) |
| Завершення терміну | TTL для кожного ключа | Кошик, сесії й кеш з автоочищенням |
| Реальний час | Pub/Sub + Streams | Залишки наживо, сповіщення, статус замовлення |
Redis (кеш) проти лише бази даних
| Критерій | З Redis | Лише PostgreSQL |
|---|---|---|
| Час відповіді для повторюваних даних | менш ніж 1 мс, з пам'яті | десятки мс, запит на кожен виклик |
| За високого трафіку | база захищена, легко масштабується | база перевантажується, ризик тайм-аутів |
| Кошик і сесії | з автоматичним завершенням | таблиці, що ростуть і навантажують базу |
| Реальний час | нативні Pub/Sub і Streams | повторюване опитування, дороге |
| Черги завдань | нативні, прості у використанні | імпровізовані рішення або їх відсутність |
Поширені запитання
Що таке Redis, коротко?
База даних у пам'яті, яку використовують як шар кешу, сесій і реального часу перед основною базою. Зберігає дані в RAM і зменшує навантаження на основну базу.
Чому ви не користуєтеся лише PostgreSQL?
PostgreSQL — джерело істини (довговічні дані), але Redis віддає повторювані дані з пам'яті та бере на себе кошик, сесії, обмеження частоти запитів і реальний час, захищаючи базу за високого трафіку. Вони працюють разом.
Чи втрачу я дані, якщо Redis вийде з ладу?
Контент сайту — ні: постійні дані зберігаються в PostgreSQL. У Redis лежать лише кеш і тимчасові дані, а персистентність RDB/AOF зменшує втрати.
Чи треба мені самому налаштовувати Redis?
Ні. Він входить у платформу 4buildsite й обслуговується нею; ви отримуєте кешування, сесії та функції реального часу, нічим не керуючи.
Як Redis допомагає інтернет-магазину?
Кошик для відвідувачів, кешовані списки товарів, залишки, що оновлюються наживо, і захист від зловживань під час оформлення замовлення та на формах — усе це без навантаження на базу даних.
Чи допомагає Redis для SEO та Core Web Vitals?
Так, опосередковано: короткий час відповіді покращує TTFB і Core Web Vitals — сигнали, що важливі і для Google, і для досвіду користувача.