Карта / Кэширование / Стратегии кэширования

Стратегии кэширования

Стратегия кэширования отвечает на вопрос: в каком порядке кэш, приложение и база участвуют в чтении и записи данных.

Cache-Aside (Lazy Loading) — самая частая стратегия. Приложение само управляет кэшем: сначала смотрит туда, если нет — идёт в базу и кладёт результат в кэш (так работает @Cacheable из предыдущей темы):

User user = cache.get(id);
if (user == null) {
    user = database.findById(id);
    cache.put(id, user);
}

Write-Through — пишешь сразу и в кэш, и в базу одновременно, синхронно:

void saveUser(User user) {
    database.save(user);
    cache.put(user.getId(), user);   // кэш всегда актуален сразу после записи
}

Write-Behind (Write-Back) — пишешь только в кэш, а в базу запись уходит асинхронно, позже, пакетом.

Копнуть глубже

Сравнение по компромиссам:

СтратегияПлюсМинус
Cache-Asideпросто, кэшируется только реально запрашиваемоепервый запрос всегда “холодный” (медленный)
Write-Throughкэш всегда свежийкаждая запись медленнее (две операции синхронно)
Write-Behindочень быстрая записьриск потерять данные, если упасть до синхронизации с базой

TTL (Time To Live) — почти всегда применяется вместе с любой стратегией: запись в кэше живёт ограниченное время, потом считается устаревшей и удаляется/перезапрашивается автоматически — это естественная защита от вечно устаревших данных, даже если явная инвалидация (см. тему «Инвалидация кэша») где-то забыта.

На практике в большинстве веб-приложений используют Cache-Aside — это самый простой и предсказуемый вариант, Write-Behind оставляют для специфичных высоконагруженных сценариев, где скорость записи критична настолько, что оправдывает риск потери данных при сбое.

🎤 Закрыл тему, если можешь объяснить:
• идею Cache-Aside и почему это самая частая стратегия;
• разницу Write-Through и Write-Behind по скорости и риску (если дошёл до 2-го слоя).