Как кэшировать, чтобы срезать нагрузку на БД при миллионах запросов/мин?

Question

IT Interview Practice · Accepted Answer

Поставьте слой **cache-aside** (Redis/Memcached) перед БД, чтобы чтения попадали в память, давайте записям **TTL** и **инвалидируйте при записи**, добавьте **защиту от stampede**, чтобы холодный ключ не обрушил thundering herd на БД, и распределяйте **горячие ключи** по репликам, чтобы один популярный ключ не расплавил один узел.

```text
                 ┌── hit ──▶ return value
request ──▶ cache│
                 └── miss ─▶ lock ─▶ DB read ─▶ set(TTL) ─▶ return
                              │
                    (only ONE miss populates; others wait)
DB writes ──▶ invalidate/update key
```

## Cache-aside против read-through

В **cache-aside** приложение проверяет кэш; при miss оно само читает БД и заполняет кэш. В **read-through** это делает за вас библиотека кэша. Так или иначе цель одна: превратить 5 мс DB-запроса в 0.2 мс memory-lookup, так что кэш с 95% hit rate режет трафик чтения БД **в 20 раз**. При миллионах запросов/мин БД просто не может обслужить каждое чтение — кэш и делает числа реальными.

## TTL + инвалидация

Два способа держать кэш свежим, и обычно нужны оба. **TTL** ограничивает устаревание — запись истекает через N секунд, так что неверные данные самоисцеляются. **Явная инвалидация** удаляет/обновляет ключ при записи ради корректности, которая не может ждать TTL. Классический баг — кэширование без инвалидации и отдача устаревших данных минутами; более тонкий — инвалидировать *и* устанавливать в одной записи, что создаёт гонку.

## Защита от stampede и горячие ключи

- **Stampede (thundering herd):** когда горячий ключ истекает, тысячи конкурентных miss бьют в БД разом и могут её повалить. Чините **per-key lock/single-flight** (только один запрос пересчитывает, остальные ждут) или **ранним/вероятностным обновлением** до истечения.
- **Горячие ключи:** один ключ (профиль знаменитости) может насытить CPU/сеть одного узла Redis. Распределяйте его — реплицируйте ключ по узлам или добавьте небольшой локальный in-process кэш перед Redis для самых горячих элементов.

## Взгляд с точки зрения интервью

Интервьюер хочет увидеть, что вы думаете дальше «добавить Redis». Хорошо: cache-aside с TTL. Отлично: вы называете **защиту от stampede, стратегию инвалидации, обработку горячих ключей и что происходит при отказе кэша**. Ловушка — считать, что кэш всегда доступен: если Redis умирает и каждый miss проваливается в БД, вы получаете **cache-avalanche**, роняющий и БД.

## Компромиссы и режимы отказа

- **Устаревание против нагрузки:** короткий TTL = свежо, но больше miss; длинный TTL = меньше miss, но устаревшее. Настраивайте под данные.
- **Cache avalanche:** множество ключей, истекающих вместе (одинаковый TTL), вызывает всплеск нагрузки — добавьте **jitter** к TTL.
- **Консистентность:** кэш и БД могут расходиться; для критичных по деньгам чтений читайте БД или используйте write-through.
- **Вытеснение из памяти:** под давлением Redis вытесняет по политике (LRU/LFU); неверная политика тихо выбрасывает ваш горячий набор.

Cache-aside против read-through

TTL + инвалидация

Защита от stampede и горячие ключи

Взгляд с точки зрения интервью

Компромиссы и режимы отказа

Похожие вопросы