Практическое руководство по очистке кэша: от ключей до отдельных вариантов

«Я очистил кэш, почему же по-прежнему вижу старое содержимое?» Это один из самых частых вопросов пользователей CDN, и ответ почти всегда связан с ключом кэша: объект, который вы удалили, и объект, к которому обращаются посетители, могут различаться. Сначала мы разберём ключи кэша, затем объясним, что именно удаляет очистка в Yeap CDN и как доставляются запросы на очистку.

Ключи кэша: как пограничный узел различает файлы

Кэшируя ответ, пограничный узел идентифицирует его по ключу кэша. В общих чертах ключ состоит из:

• значения имени хоста, например www.example.com;
• значения пути, например /assets/app.js;
• значения нормализованной строки запроса в зависимости от режима обработки параметров, заданного для домена;
• и, при необходимости, дополнительных признаков варианта, например кодировки содержимого.

Два запроса обращаются к одному кэшированному объекту только при совпадении ключей. Поэтому /app.js?v=1 и /app.js?v=2 по умолчанию являются разными объектами, а параметр версии заставляет и браузер, и CDN загружать новый файл.

Режимы обработки строки запроса

На странице CDN → Домены → Кэш в консоли можно выбрать, как домен обрабатывает строки запроса. На странице также отображается предварительный просмотр ключа кэша, обновляемый при изменении настроек:

На внутреннем уровне пограничный узел всегда декодирует параметры, сортирует их по имени (а также сортирует повторяющиеся значения одного имени), затем заново кодирует перед формированием ключа. Поэтому в любом режиме, сохраняющем параметры, их порядок не создаёт дубликатов объектов. Повторное кодирование тоже важно: оно гарантирует, что символ & или = внутри декодированного значения не создаст неоднозначную строку, а значит, два разных запроса не получат один ключ кэша.

Типичная оптимизация: маркетинговые ссылки часто содержат разнообразные параметры отслеживания, и каждая уникальная комбинация создаёт новый объект, снижая долю попаданий в кэш. Исключение таких параметров через список запрещённых обычно заметно повышает эту долю.

Что именно удаляет очистка

Нажмите Очистить кэш в правом верхнем углу страницы настроек кэша и выберите один из двух вариантов.

Очистить всё

Удаляет все кэшированные объекты домена на всех пограничных узлах. Используйте для крупных выпусков или когда не уверены, что изменилось. Цена такой очистки — временная отправка всех запросов на сервер-источник, из-за чего нагрузка на него ненадолго возрастает.

Очистить по URL

Введите полные URL, по одному на строку. Для понимания поведения очистки важны следующие правила:

• Без строки запроса, например https://www.example.com/list: удаляются все варианты строки запроса для этого пути, включая /list, /list?page=2, /list?page=3 и так далее.
• Со строкой запроса, например https://www.example.com/list?page=2: удаляется только этот вариант; /list?page=3 остаётся в кэше.

При очистке со строкой запроса она нормализуется по тем же правилам, что и при формировании ключей кэша (тот же режим, сортировка и кодирование). Поэтому, даже если кэшированный запрос имел вид ?b=2&a=1, ввод ?a=1&b=2 удалит именно его.

Мы реализовали это поведение по отзывам пользователей. Ранняя версия индекса очистки сравнивала только хост и путь, поэтому очистка ?a=3 могла завершиться сообщением об успехе, хотя объект по-прежнему выдавался из кэша: ключ кэша включал строку запроса, а сопоставление при очистке — нет. Теперь каждая запись индекса очистки содержит нормализованную строку запроса, и сопоставление выполняется на уровне вариантов.

Модель очистки пограничных узлов также поддерживает сопоставление по префиксу, маске и тегам; сейчас в консоли доступны очистка всего сайта и очистка по URL.

Как запросы на очистку достигают каждого узла

После подтверждения консоль отвечает почти сразу, поскольку доставка задания на очистку не выполняется синхронно в рамках вашего HTTP-запроса:

1. Плоскость управления помещает задание на очистку (домен и список путей) в фоновую очередь на базе Redis и сразу возвращает ответ.
2. Обработчики очереди параллельно доставляют задание пограничным узлам, обслуживающим домен, с автоматическими повторными попытками при сбое.
3. Если сама очередь недоступна, плоскость управления переходит на синхронную доставку, поэтому задание на очистку не теряется.

На пограничном узле полная очистка состоит из двух частей: найти все подходящие ключи хранилища в индексе очистки, затем удалить эти объекты из хранилища кэша и из горячего слоя в памяти. Чтобы несколько каналов доставки не мешали друг другу, индекс изменяет только тот канал, который может надёжно удалять объекты из хранилища в асинхронном контексте. Остальные выполняют сопоставление без изменения индекса и очищают горячий слой. Какой бы канал ни сработал первым, в итоге очистка выполняется полностью.

Как проверить

Ответы пограничных узлов содержат заголовок X-Cache-Status. После очистки выполните проверку через curl:

curl -sI "https://www.example.com/list?page=2" | grep -i x-cache-status
# first request after the purge: X-Cache-Status: MISS
# request again:                 X-Cache-Status: HIT

Если после очистки вы по-прежнему видите старое содержимое, проверяйте в таком порядке:

• Не используется ли кэш браузера? Очистка пограничного кэша не затрагивает копии, уже сохранённые в браузерах посетителей. Проверьте через curl или в приватном окне.
• Совпадает ли имя хоста во введённом URL с реальным запросом? example.com и www.example.com — разные кэши.
• Не выдаёт ли сервер-источник старое содержимое? После очистки пограничный узел снова обращается к серверу-источнику, поэтому, если перед ним есть ещё один кэш, его тоже нужно обновить.

Рекомендация: как можно реже полагайтесь на очистку

Очистка полезна, но для статических ресурсов надёжнее всего менять URL вместе с содержимым:

• Используйте имена файлов с хэшем содержимого, например app.3f9a1c.js, и задавайте им длительный срок хранения в кэше. Новая версия получает новый URL, поэтому очищать ничего не нужно.
• Задавайте входным HTML-страницам короткий срок хранения в кэше, чтобы они быстрее подхватывали новые URL ресурсов.
• Если очистка всё же нужна, предпочитайте очистку по URL, а очистку всего сайта оставляйте для масштабных изменений.

Когда понятен ключ кэша, очистка перестаёт быть гаданием: удаляется именно тот ключ, для которого она выполняется.