Какие виды инвалидации кэша ты знаешь? Каким пользовался на практике?

Что такое инвалидация кэша и зачем она нужна

Кэширование ускоряет чтение данных, но создаёт проблему согласованности: данные в кэше могут устареть, если источник (база данных) изменился. Инвалидация кэша — это механизм, который гарантирует, что клиент получает актуальные данные, удаляя или обновляя устаревшие записи. Без неё пользователи видят старые значения, что критично для финансовых систем, корзин интернет-магазинов и любых приложений с частыми обновлениями.

Основные стратегии инвалидации

• TTL (Time To Live) — каждой записи задаётся срок жизни, после которого она автоматически удаляется. Просто и надёжно, но возможна выдача устаревших данных до истечения TTL.
• Инвалидация по событию — при изменении данных в БД приложение явно удаляет или обновляет соответствующий ключ в кэше. Гарантирует актуальность, но требует продуманной логики.
• Write-through — запись сначала идёт в кэш, затем в БД. Кэш всегда актуален, но увеличивает задержку записи.
• Write-back — запись идёт только в кэш, а в БД асинхронно позже. Быстро, но есть риск потери данных при сбое.
• Cache-aside — приложение само управляет кэшем: сначала читает из кэша, при промахе — из БД и заполняет кэш. Инвалидация обычно по событию или TTL.

Практический пример с Redis и Node.js

// Чтение с cache-aside и TTL
const getProduct = async (id) => {
  const cached = await redis.get(`product:${id}`);
  if (cached) return JSON.parse(cached);
  const product = await db.findProduct(id);
  await redis.set(`product:${id}`, JSON.stringify(product), 'EX', 3600);
  return product;
};

// Инвалидация по событию при обновлении
const updateProduct = async (id, data) => {
  await db.updateProduct(id, data);
  await redis.del(`product:${id}`); // удаляем устаревший ключ
};

В этом примере TTL защищает от «вечного» устаревания, а явное удаление при обновлении гарантирует мгновенную актуальность для часто меняющихся данных.

Вывод

На практике комбинируют TTL для редко меняющихся данных и инвалидацию по событию для критичных обновлений. Выбор стратегии зависит от требований к согласованности и допустимой нагрузки на БД. Для большинства веб-приложений cache-aside с TTL и точечной инвалидацией — оптимальный баланс простоты и эффективности.