Инвалидация кэша

Почему инвалидация — трудная проблема

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

Три подхода

Прежде чем выбирать, спроси себя: насколько неверным может быть чтение и кто заплатит, если инвалидация пропустила точку? Ответ скажет, какой компромисс тебе подходит.

• Истечение по TTL — пусть каждая запись истекает через N секунд; путь записи не делает ничего. Это проще всего и максимально расцеплено: кэш самоисцеляется, писатели его не трогают. Цена — ограниченное устаревание: значение может быть неверным до TTL. Верный дефолт для данных, терпящих секунды-минуты лага (ленты, листинги, отрендеренные фрагменты).
• Явная инвалидация — на каждой записи активно удалять (или обновлять) затронутый ключ кэша, чтобы следующее чтение перезагрузило. Устаревание падает к нулю, но теперь путь записи сцеплен с кэшем: он должен знать каждый ключ, выведенный из изменённых данных, и единственная пропущенная точка инвалидации оставляет ключ устаревшим навсегда (до его TTL, если есть). В этом сцеплении живёт большинство багов кэша.
• Версионированные ключи — впеки версию в сам ключ: user:42:v7. Запись ничего не удаляет; она инкрементит версию (v7 → v8), так что чтения новой версии просто промахиваются по ключу, что никогда не записывался, и грузят свежее, а старые записи v7 теперь сироты, со временем вытесняемые. Это полностью обходит гонку удаления (ты никогда не мутируешь существующий ключ) ценой оставленного мусора на вытеснение и нужды где-то отслеживать текущую версию.

Senior-формулировка зеркалит урок про стратегии: бесплатного варианта нет. TTL прост, но устаревает; явная свежа, но сцеплена и подвержена гонкам; версионирование без гонок, но оставляет сирот и нуждается в источнике версий. Выбираешь поклассово и обычно комбинируешь — явную инвалидацию с TTL-подстраховкой, чтобы пропущенная инвалидация самоисправилась, а не отравляла навсегда.

Устаревшие чтения, негативное кэширование и dogpile

Ещё три опасности сидят вокруг инвалидации:

• Устаревшие чтения — принятая цена TTL/ленивых стратегий, но они становятся багом корректности, когда класс данных их не терпит (баланс-показанный-с-часовым-опозданием из урока про стратегии). Починка не «никогда не устаревать» — а сопоставить бюджет устаревания данным: ограничь коротким TTL или плати цену сцепления явной инвалидации там, где это реально важно.
• Негативное кэширование — кэшировать отсутствие значения («не найдено»), чтобы повторные поиски отсутствующего ключа не молотили базу каждый раз. Жизненная защита от потока промахов по несуществующим ключам (например, атакующий запрашивает случайные ID), но у неё своя проблема инвалидации: когда сущность наконец создаётся, слишком долгий TTL негативного кэша её прячет. Негативным записям нужны короткие TTL или явная инвалидация при создании.
• Dogpile — стампида из урока про распределённый кэш сама по себе событие инвалидации: инвалидация (удаление) горячего ключа создаёт мгновенный зазор, который N параллельных читателей бросаются заполнить. Так что инвалидация и защита от стампиды сцеплены: агрессивное «удаляй на каждой записи» на горячем ключе и есть триггер стампиды — поэтому горячие ключи часто предпочитают обновление-на-месте или версионирование удалению.

Глубочайший анти-паттерн: кэш как источник истины

Самая опасная ошибка — не гонка; это категориальная ошибка. Кэш — это одноразовая копия авторитетных данных, живущих в надёжном хранилище. Считай его источником истины — пиши только в кэш и лениво сбрасывай, или предполагай «если оно в кэше, оно верно» — и ты построил систему, теряющую данные при перезапуске кэша (он не надёжен), отдающую что попало закэшировалось, даже когда БД не согласна, и неперестраиваемую с нуля, ведь никто не знает реального состояния. Каждая стратегия инвалидации выше предполагает, что база авторитетна, а кэш расходуем: ты должен иметь возможность сбросить весь кэш в любой момент и чтобы система восстановилась (медленно, через промахи) к корректным ответам. Если сброс кэша потерял бы данные или отдавал бы неверные результаты бесконечно — это не кэш, а ненадёжная primary-база, и ты унаследовал все её проблемы консистентности без единой её гарантии.