Стратегии кэширования
Стратегия кэширования отвечает на вопрос: в каком порядке кэш, приложение и база участвуют в чтении и записи данных.
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 оставляют для специфичных высоконагруженных сценариев, где скорость записи критична настолько, что оправдывает риск потери данных при сбое.
• разницу Write-Through и Write-Behind по скорости и риску (если дошёл до 2-го слоя).