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

Главная боль кэша — не как класть данные, а как вовремя их обновлять.

Инвалидация кэша — удаление или обновление устаревших данных в кэше. Известная шутка: «в информатике две трудные задачи — инвалидация кэша и придумывание имён».

Cache-aside (lazy loading)

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

ЧТЕНИЕ:
  есть в кэше? → да: вернуть
               → нет: прочитать из БД, положить в кэш, вернуть
ЗАПИСЬ:
  записать в БД, затем удалить ключ из кэша

Плюс: в кэше только то, что реально запрашивают. Минус: первый запрос после промаха медленный, и есть окно, когда кэш и база рассинхронны.

Write-through

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

Write-back (write-behind)

Запись идёт в кэш, а в базу сбрасывается позже, пачкой (асинхронно). Запись очень быстрая, база разгружена. Расплата — риск потерять данные, если кэш упал до сброса. Применяют там, где скорость записи критична, а редкая потеря терпима (счётчики, метрики).

Сравнение стратегий

TTL и устаревание

TTL (time to live) — срок жизни записи в кэше, после которого она сама удаляется. Это страховка от вечно устаревших данных: даже если забыли инвалидировать вручную, через TTL запись протухнет и перечитается из базы. Подбор TTL — компромисс: короткий → свежее данные, но больше промахов и нагрузки на базу; длинный → меньше нагрузки, но выше риск отдать устаревшее.

Опасные эффекты

Итог

• Cache-aside — гибко и популярно; write-through — согласованно, но медленнее; write-back — быстро, но рискует потерей.
• TTL — страховка от устаревания: даже без ручной инвалидации запись протухнет сама.
• Берегитесь cache stampede и пустого кэша после рестарта — прогревайте и блокируйте перечитывание.