Какие стратегии и паттерны кэширования существуют в Redis?

Question

Accepted Answer

Помимо базового cache-aside, существует несколько **стратегий кэширования** — cache-aside, write-through, write-behind, read-through — каждая с различными компромиссами между согласованностью и производительностью. Понимание их (и политик вытеснения) помогает разработать эффективное кэширование.

## Cache-aside (ленивая загрузка — наиболее распространённая)

```text
App checks cache → miss → load from DB → populate cache → return.
  ✓ Only requested data is cached (efficient); resilient (works if cache is down)
  ✗ First request is a miss (slower); cache can be stale until TTL/invalidation
→ The default, most common strategy.
```

## Write-through и write-behind

```text
WRITE-THROUGH → write to cache AND DB together (synchronously) on every write
  ✓ Cache always fresh/consistent  ✗ Writes are slower (two writes); caches unread data

WRITE-BEHIND (write-back) → write to cache immediately, write to DB ASYNC later
  ✓ Fast writes  ✗ Risk of data loss if cache fails before the DB write; more complex
```

## Read-through

```text
READ-THROUGH → the cache layer itself loads from the DB on a miss (abstracted)
  → app just reads from the cache; the cache handles DB loading transparently
  (similar to cache-aside but the loading logic lives in the cache layer/library)
```

## Политики вытеснения (когда память заполнена)

```text
When Redis hits its memory limit (maxmemory), it EVICTS keys per a policy:
  LRU (Least Recently Used)  → evict least-recently-accessed (good general default)
  LFU (Least Frequently Used)→ evict least-frequently-accessed
  TTL-based (volatile-ttl)   → evict keys closest to expiry
  random / noeviction        → random, or reject writes when full
→ allkeys-lru is a common choice for a pure cache. Set maxmemory + a policy.
```

## Избежание проблем кэша

```text
✓ Cache STAMPEDE (many misses at once hammering the DB) → locking, staggered TTLs
✓ Stale data → appropriate TTLs + invalidation on writes
✓ Cache PENETRATION (querying non-existent keys) → cache negative results briefly
```

## Почему это важно

Понимание стратегий кэширования ценно для **проектирования эффективных систем кэширования**, расширяя базовый cache-aside, поэтому это полезное знание для работы, сосредоточенной на производительности.

Хотя cache-aside (ленивая загрузка — проверка кэша, загрузка из БД при промахе, заполнение кэша) — это общий стандартный подход, понимание **диапазона стратегий** позволяет выбрать нужную для ситуации: **write-through** (запись в кэш и БД одновременно для всегда свежего кэша ценой более медленной записи), **write-behind** (немедленная запись в кэш и асинхронная запись в БД для быстрой записи, но с риском потери данных), и **read-through** (слой кэша прозрачно загружает из БД) — каждая с отчётливыми компромиссами согласованность/производительность, которые имеют значение для различных требований к согласованности и паттернам записи.

Понимание **политик вытеснения** (LRU, LFU, основанные на TTL и т. д. — как Redis решает, какие ключи удалить при заполнении памяти) важно для правильной настройки Redis как кэша (установка `maxmemory` и подходящей политики, такой как `allkeys-lru` для чистого кэша), поэтому он ведёт себя хорошо под давлением памяти.

Знание того, как **избежать распространённых проблем кэша** — cache **stampede** (множество одновременных промахов, перегружающих базу данных, смягчается блокировкой или шахматной распределением TTL), **устаревшие данные** (управляются с помощью TTL и инвалидации) и **проникновение кэша** (повторные запросы для несуществующих ключей, смягчается кэшированием отрицательных результатов) — отражает зрелое проектирование кэша, которое избегает реальных проблем в production.

Поскольку эффективное кэширование значительно влияет на производительность, а правильная стратегия/конфигурация зависит от варианта использования, и поскольку понимание стратегий, политик вытеснения и распространённых ошибок позволяет проектировать надёжное кэширование, понимание стратегий и паттернов кэширования — это ценное, практически релевантное знание для инженерии производительности с Redis, поднимающее кэширование от базового паттерна к хорошо спроектированным системам, которые правильно обрабатывают согласованность, память и режимы отказа.