Налаштування Redis для кешування веб-додатку: повний гайд

Налаштування Redis для кешування веб-додатку

Redis — не просто кеш. Це структури даних в пам'яті: рядки, хеші, списки, множини, sorted sets, потоки, pub/sub. Правильно обрана структура часто дає чистіше рішення, ніж спроба зробити те саме в реляційній базі. На практиці ми стикалися з проектами, де заміна N+1 запитів на кешований хеш знижувала час відповіді з 2 секунд до 50 мс — приріст у 40 разів. При цьому неправильна конфігурація Redis (наприклад, відсутність ліміту пам'яті або невірна політика витіснення) призводила до падіння продакшену. Як цього уникнути — розповімо нижче. Економія бюджету на інфраструктурі може досягати 70% при правильному налаштуванні.

Чому Redis швидший за класичне кешування в БД?

Кешування в реляційній базі (наприклад, MySQL MEMORY table) має обмеження за об'ємом, швидкістю та гнучкістю структур даних. Redis зберігає дані в оперативній пам'яті з прямим доступом, підтримує атомарні операції та складні структури (sorted sets для рейтингів, streams для черг). У наших тестах Redis обробляє 100–200 тисяч операцій читання/запису в секунду на одному ядрі — в 10–20 разів швидше, ніж кешування через БД. Це досягається за рахунок однопотокової моделі та оптимізації під RAM. В одному проекті ми перейшли з MySQL-кешу на Redis і знизили навантаження на БД на 80% — база перестала бути вузьким місцем. Як зазначено в документації Redis: "Redis is an open source, in-memory data structure store, used as a database, cache, and message broker."Redis documentation

Як вибрати стратегію інвалідації кешу?

Cache-aside — найпоширеніший патерн: додаток спочатку перевіряє кеш, при промаху завантажує з БД та зберігає в кеш з TTL. Ідеальний для даних, які оновлюються рідко. Write-through — запис у кеш та БД синхронно. Підходить для даних з високою частотою змін (наприклад, кошик користувача).

Реалізуємо cache-aside на TypeScript з ioredis:

import { Redis } from 'ioredis' export class CacheService { constructor(private redis: Redis) {} async getOrSet<T>( key: string, ttlSeconds: number, factory: () => Promise<T> ): Promise<T> { const cached = await this.redis.get(key) if (cached !== null) { return JSON.parse(cached) as T } const value = await factory() await this.redis.setex(key, ttlSeconds, JSON.stringify(value)) return value } async invalidate(pattern: string): Promise<void> { let cursor = '0' do { const [nextCursor, keys] = await this.redis.scan(cursor, 'MATCH', pattern, 'COUNT', 100) cursor = nextCursor if (keys.length > 0) { await this.redis.unlink(...keys) } } while (cursor !== '0') } } const product = await cache.getOrSet( `product:${id}`, 300, () => db.products.findOne({ id }) ) await cache.invalidate(`product:${id}`) 

Write-through — запис у кеш та БД синхронно:

async updateProduct(id: string, data: UpdateProductDto) { const updated = await db.products.update(id, data) await redis.setex(`product:${id}`, 600, JSON.stringify(updated)) return updated } 

Порівняння cache-aside та write-through

Як налаштувати Redis для кешування: покрокова інструкція

1. Встановіть Redis через пакетний менеджер: sudo apt install redis.
2. Налаштуйте maxmemory та політику витіснення, наприклад allkeys-lru.
3. Увімкніть персистентність: AOF з fsync everysec.
4. Реалізуйте патерн кешування (cache-aside або write-through).
5. Налаштуйте моніторинг: slowlog, info stats, --latency-history.
6. Для відмовостійкості налаштуйте Sentinel або Cluster.
7. Протестуйте під навантаженням та оптимізуйте TTL.

Сесії користувачів в Redis

Зберігання сесій в Redis — стандарт для високонавантажених додатків. Використовуємо sliding window з автоматичним продовженням TTL:

const SESSION_TTL = 86400 * 7 export class SessionService { constructor(private redis: Redis) {} async create(userId: string, metadata: SessionMeta): Promise<string> { const sessionId = crypto.randomUUID() const key = `session:${sessionId}` await this.redis.hset(key, { userId, createdAt: Date.now(), ip: metadata.ip, userAgent: metadata.userAgent }) await this.redis.expire(key, SESSION_TTL) await this.redis.zadd(`user:${userId}:sessions`, Date.now(), sessionId) await this.redis.expire(`user:${userId}:sessions`, SESSION_TTL) return sessionId } async get(sessionId: string): Promise<SessionData | null> { const data = await this.redis.hgetall(`session:${sessionId}`) if (!Object.keys(data).length) return null await this.redis.expire(`session:${sessionId}`, SESSION_TTL) return data as SessionData } async destroyAll(userId: string): Promise<void> { const sessionIds = await this.redis.zrange(`user:${userId}:sessions`, 0, -1) if (sessionIds.length) { const keys = sessionIds.map(id => `session:${id}`) await this.redis.unlink(...keys, `user:${userId}:sessions`) } } } 

Rate limiting через sliding window

async function rateLimit( redis: Redis, key: string, limit: number, windowMs: number ): Promise<{ allowed: boolean; remaining: number; resetAt: number }> { const now = Date.now() const windowStart = now - windowMs const pipeline = redis.pipeline() pipeline.zremrangebyscore(key, '-inf', windowStart) pipeline.zadd(key, now, `${now}-${Math.random()}`) pipeline.zcard(key) pipeline.pexpire(key, windowMs) const results = await pipeline.exec() const count = results![2][1] as number return { allowed: count <= limit, remaining: Math.max(0, limit - count), resetAt: now + windowMs } } 

Sentinel для високої доступності

Для критичних систем налаштовуємо Redis Sentinel з автоматичним failover.

sentinel monitor mymaster 10.0.0.1 6379 2 sentinel auth-pass mymaster your_password sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 10000 sentinel parallel-syncs mymaster 1