CDN cache invalidation: почему устаревший контент живёт часами
Правка выложена на источник, выкладка прошла без ошибок — а пользователи ещё часами получают прошлую версию страницы. Причина не в релизе: между источником и браузером стоит кэш со своим сроком жизни, и он не знает, что контент обновился. CDN cache invalidation в такой схеме остаётся ручной операцией из панели, а не частью процесса публикации.
Корень — в рассинхронизации версий. Срок жизни кэша задан числом: сутки на статику, минуты или часы на разметку. Публикация же — это событие. Пока эти две сущности живут порознь, каждый выпуск превращается в лотерею: часть узлов уже отдаёт новый ответ, часть держит старый, и конкретный пользователь видит ту версию, которую успел закэшировать первым.
Плата измерима, и платит её не инфраструктура, а поддержка. Жалобы на старую версию приходят туда, а не к инженерам, и разбор каждой заявки начинается с вопроса «кэш чистили?». Дальше — ручные сбросы по URL или по целой зоне через панель управления, например Cloudflare, где опечатка в пути оставляет устаревший контент жить дальше без всяких сигналов.
Отдельная боль — сброс всей зоны «на всякий случай»: он снимает нагрузку с кэша и обрушивает трафик на источник, а следующая правка снова требует ручной операции. Разбираем, как это закрывается: привязкой инвалидации к публикации, сбросом по тегам вместо зон и проверкой, что после выкладки все узлы отдают новую версию.
Что даёт автоматизация сброса: сроки, попадания, доля отказов
Автоматический сброс строится не на полной очистке кэша, а на метках: сборка проставляет теги на группы объектов — каталог, карточку, статику, — а публикация отправляет на периферию только список изменившихся меток. Полная очистка заставляет край заново тянуть весь контент с источника, и при частых релизах это самая дорогая операция из возможных. Меточный режим сбрасывает десятки объектов вместо миллионов.
На графиках это видно сразу: доля попаданий в кэш перестаёт пилообразно проваливаться после каждого релиза и держится в коридоре, близком к верхней границе. Нагрузка на источник становится ровной — исчезают всплески, когда весь край одновременно перезапрашивает одни и те же страницы.
Скорость публикации меняется качественно: правка доходит до пользователя за секунды, а не по истечении времени жизни объекта в кэше. Заодно уходит целый класс отказов — «полуобновлённый релиз», когда браузер получает новую разметку со старым оформлением или скриптом. Сброс связанных меток одним набором закрывает эту рассинхронизацию.
Платформы вроде Cloudflare умеют сбрасывать по меткам почти мгновенно, но без правил тегирования каждый релиз превращается в ручной список путей. Мы описываем схему меток один раз — дальше сброс вызывается из конвейера сборки и не зависит от того, кто именно выпускает изменение.
Способы сброса: по тегу, по пути, по версии сборки
Инвалидация на границе не атомарна: пока команда расходится по десяткам узлов, часть посетителей получает свежий объект, часть — прежний. Точность сброса и скорость распространения связаны обратной зависимостью, поэтому выбор способа — это выбор класса отказов, который вы готовы терпеть.
Ломается у соседних вариантов разное: по тегу — забытый тег на новом ресурсе, по пути — неучтённый параметр в адресе, полный сброс — удар всей нагрузки по источнику. Ниже — границы применимости каждого.
| Вариант | Когда подходит | Чем платите |
|---|---|---|
| Сброс по тегу | один объект входит в десятки страниц: каталог, карточка, выдача | каждый ответ источника должен нести тег; пропущенный тег — залипший контент до конца срока жизни |
| Сброс по пути или шаблону | статика и страницы с предсказуемым адресом | границы шаблона: параметры в адресе, лимит на число путей в одном запросе |
| Версионирование сборок | собранные скрипты, стили, шрифты | прежние версии живут до конца срока; нужен реестр активных ключей |
| Полный сброс | аварийный случай, ошибка в данных | шторм запросов на источник и просадка базы; узлы обновляются неравномерно |
На практике способы комбинируют: версия сборки — для статики, теги — для ответов с данными, полный сброс оставляют аварийным рычагом с отдельными правами доступа.
Внедрение: от инвентаризации контента до регламента сброса
Инвалидация кэша — не один вызов в момент релиза, а последовательность, где каждый шаг оставляет проверяемый результат. Если пропустить инвентаризацию или зависимости, после публикации пользователи получают смесь версий: разметка обновилась, а стили или данные карточки — нет. Порядок работ, по которому мы ведём внедрение:
-
Инвентаризация контента. Размечаем всё, что отдаётся через кэш: статика с версией в имени, страницы, ответы сервисов, медиа. Для каждого типа фиксируем допустимое время жизни — результат оформляем таблицей «тип — срок жизни — способ сброса».
-
Схема зависимостей. Строим карту объектов, которые меняются вместе: страница каталога и карточка, шаблон и общий фрагмент, лента и её элементы. Без неё адресный сброс оставляет несовместимые сочетания — получаем граф связей и список составных объектов.
-
Настройка правил сброса. Уходим от полной очистки к адресной: сброс по меткам, отдельные правила для путей с параметрами, разделение жёсткого и мягкого режима. Результат — конфигурация правил в системе контроля версий.
-
Автоматизация в конвейере публикации. Вызов сброса становится шагом выпуска и срабатывает после успешного развёртывания, с повторами при сбое и защитой от дублирования. Результат — шаг выпуска и журнал обращений вместо ручных сбросов.
-
Проверка после публикации. Сверяем метки версии и заголовки ответов на выборке узлов в разных регионах, а не на одном. Результат — автоматические проверки и отчёт о согласованности.
-
Регламент и откат. Описываем действия при неудачном сбросе, лимиты частоты и защиту от лавины обращений. Результат — регламент и отработанный сценарий отката к предыдущей версии.
На выходе получается не набор скриптов, а управляемый процесс: сброс запускается публикацией, а не вручную, и подтверждается проверками.
Конфигурации, схемы зависимостей и регламенты сброса
Комплект собран так, чтобы дежурная смена работала без нас: инженер открывает документ, находит нужное правило, сбрасывает кэш и понимает, что проверить после. Ниже — что именно остаётся у вас на руках вместе с настроенной автоматизацией CDN cache invalidation.
- Карта правил кэширования — какие пути и типы ответов кэшируются, какое время жизни задано и какие заголовки источника его переопределяют.
- Схема зависимостей — граф «страница → шаблон → общие блоки → данные», по которому видно, что инвалидировать при правке одного компонента, не очищая весь домен.
- Регламент сброса — порядок действий для трёх сценариев: точечная правка, релиз раздела, аварийный откат на предыдущую версию.
- Шаблоны запросов — сброс по адресу, по префиксу пути и по метке, с очерёдностью и лимитами, чтобы не выйти за квоты провайдера.
- Привязка к публикации — правило, запускающее сброс после выкладки статики, с защитой от повторных срабатываний при перезапуске шага сборки.
- Чек-лист проверки — эталонный запрос, сравнение заголовков ответа и контроль на нескольких узлах: как убедиться, что объект действительно обновлён.
- Матрица ответственности — кто сбрасывает при штатном релизе, кто подтверждает результат и кого поднимать при расхождении между узлами.
- Документация по кэшу и журнал инцидентов — принятые решения, обходные пути и разбор случаев, когда сброс не сработал с первого раза.
Всё лежит рядом с конфигурацией в вашем репозитории, с версионированием: изменения регламента проходят ревью так же, как код.
Кейс: задержка обновления сократилась с часов до минут
Что было
Издание с посещаемостью в миллионы страниц в сутки держало HTML и статику на CDN с длинным сроком жизни в кэше. Доля попаданий держалась около 60%, источник был спокоен — до первой срочной публикации. Правку на краю сети видели только после ручного сброса, и дежурный сбрасывал кэш целиком по зоне: редакция ждала обновления от 40 минут до нескольких часов.
Плата за это — всплеск на источнике. После полного сброса все краевые узлы шли за одними и теми же объектами: запросы к источнику росли кратно, время ответа увеличивалось, часть заканчивалась ошибкой. Кэш в часы пик старались не трогать, поэтому правки копились до ночи.
Что изменили
Перешли на сброс по тегам: каждой сущности — материалу, разделу, шаблону — присвоен ключ, и инвалидация идёт по ключу, а не по адресам. Статику с хешем в имени выпустили с длинным сроком и пометкой «неизменяемая», HTML — с коротким сроком и отдачей устаревшей копии, пока подтягивается свежая. Сброс стал шагом выпуска: выкладка, инвалидация затронутых тегов, подтверждение от API и только затем переключение указателя на новую версию. Работаем через Cloudflare — её API сброса по тегам убрал ручные операции.
Что получилось
Задержка обновления упала с часов до десятков секунд: медиана — около 40 секунд, 95-й процентиль — меньше двух минут. Доля попаданий в кэш выросла с 60% до 96%, потому что длинные сроки стали безопасными. Нагрузка на источник в момент сброса растёт в пределах 10–15% вместо кратного всплеска: отказов нет, а возврат к предыдущей версии занимает секунды — достаточно вернуть прежний указатель.
Чем отличается инвалидация по тегу от сброса по путям?
Сброс по путям — явный список адресов: приложение перечисляет URL, которые нужно убрать из кэша. Тег-инвалидация работает иначе: объект при отдаче помечается набором меток, и один вызов по метке снимает всё, что к ней привязано. Разница не в скорости ответа, а в том, кто отвечает за полноту списка — приложение или кэш.
| Подход | Когда подходит | Ограничения |
|---|---|---|
| Сброс по путям | Точечные правки, небольшой набор предсказуемых адресов | Не атомарен: сброс идёт постранично. Полноту списка держит приложение, каждый новый шаблон адреса требует обновления правил |
| Тег-инвалидация | Каталоги, ленты, карточки, где одна сущность отдаётся по многим адресам | Нужна поддержка меток на стороне раздачи и разметка в приложении, есть лимит меток на объект, ошибка в простановке ключа тихо оставляет запись в кэше |
| Версионирование имён | Статика: скрипты, стили, изображения, шрифты | Нужна сборка, где имя меняется вместе с содержимым; не работает для адресов, которые нельзя переписать |
Поведение при частичном срабатывании различается сильнее, чем кажется. Если в списке путей не хватило одного адреса — например, страницы каталога с фильтром — пользователи видят смесь версий разного возраста, и расхождение держится до истечения времени жизни записи. Тег-инвалидация сбрасывает набор целиком, но частичный результат всё равно возможен: объект, которому ключ не проставили при отдаче, остаётся в кэше и незаметно выпадает из сброса — поэтому метки стоит проверять тем же набором тестов, что и сами страницы.
При смешанном контенте подходы не конкурируют. Статику раздают под версионированными именами, динамические страницы и фрагменты помечают метками, а сброс по путям оставляют для точечных правок вроде редиректа или страницы акции. Метки при этом заводят по смысловым сущностям — карточка, категория, лента — чтобы публикация одного объекта не сбрасывала весь кэш и не заставляла источник пересобирать всё заново.
Вопросы, которые всплывают на этапе настройки сброса
На этапе настройки всплывают сомнения, которых не видно в демо: можно ли сбросить только изменившиеся объекты, что делать при частых правках в разгар акции и как это работает, если контент уходит через несколько сетей доставки. Ниже — короткие ответы по каждому пункту, чтобы решение можно было оценить по рискам, а не по обещаниям.
Сброс всего кэша или только части?
Полный сброс бьёт по кэшу целиком: следующий всплеск трафика уходит на сервер-источник, и время ответа растёт на всех страницах, а не только на изменённой. Поэтому объекты размечаются тегами кэша — по разделу, шаблону страницы или идентификатору товара — и при публикации сбрасывается лишь затронутая группа. Правка одной карточки не задевает каталог и главную.
Есть ли ограничения на частоту обращений?
Да, и у каждой сети доставки они свои. При массовых правках — импорт каталога, ночная выкатка — запросы ставятся в очередь, объединяются и дедуплицируются: тысяча изменений уходит одним пакетом, а не тысячей обращений. Добавляем задержку на схлопывание серии правок и отдельный приоритет для срочных, чтобы не упереться в лимит в момент распродажи.
Контент раздаётся через несколько независимых сетей — как быть?
Тогда сброс нельзя запускать из панели одной из них. Нужен единый слой управления: событие публикации вызывает рассылку во все сети, каждая получает свой набор тегов, а состояние сброса фиксируется — повторный запуск не дублирует работу. Разное время распространения проверяется по контрольному объекту, и только после этого задача считается закрытой.
Обсудим вашу схему обновления контента
Оценка «по описанию» почти всегда уходит в сторону: схема сброса кэша зависит от того, как контент рождается, с какой частотой меняется и что уже настроено на периметре. Чтобы считать по факту, а не на предположениях, пришлите следующее.
- состав контента: статика, страницы каталога, персональные ответы, медиа — что кэшируется на общем уровне, а что адресно;
- частоту и характер правок: плановые релизы, поток обновлений цен и остатков, срочные снятия материалов;
- текущие правила кэширования: заголовки управления, время жизни объектов, ключи, по которым формируется кэш;
- журналы обращений к периметру за несколько недель: доля попаданий в кэш, коды ответов, самые частые адреса;
- сценарии аварий: что публиковали, какой контент оставался устаревшим, как долго это держалось и как гасили;
- доступы: панель управления периметром, репозиторий конфигурации, инструменты публикации — на чтение достаточно.
В ответ вернём разбор по категориям: где хватает короткого времени жизни объекта, где нужен сброс по метке, а где — версионирование адреса. Отдельно покажем, сколько запросов на сброс уходит при обычном релизе и при массовой правке, и предложим порядок внедрения с точками отката.
