HTTP-кэширование выглядит простым; правильная настройка ключа кэша и обработки исключений в production — сложная задача.
HTTP-кэширование теоретически просто: когда значения Cache-Control, ETag и TTL верны, клиенты и посредники повторно используют один и тот же ответ. В production приложения систематически отправляют эти заголовки отсутствующими, неверными или излишне ограничительными. В результате кэшируемый контент продолжает неоправданно обращаться к backend.
Даже для статических ресурсов небольшие различия в URL снижают эффективность кэша. Одно и то же изображение продукта или страница каталога может вести себя как другой объект из-за параметров отслеживания. Хост, строка запроса, заголовки клиента или неправильно настроенный заголовок Cache-Control без необходимости снижают коэффициент попаданий в кэш.
Для динамического контента проблема масштабнее. Один и тот же путь может возвращать разные ответы для мобильных и настольных устройств; цены могут варьироваться в зависимости от страны; один и тот же эндпоинт может производить разные данные для каждого тенанта. Если ключ кэша не несёт этот контекст, возвращается неверный контент. Добавьте слишком много заголовков в ключ кэша — и кэш почти перестаёт работать.
Внешние решения для кэширования или CDN полезны на границе интернета, но не всегда подходят для локального, частного API или суверенного облачного трафика. Кэширование на слое ADC обычно требует конфигурационных файлов, пользовательского языка правил или отдельного продукта.
TR7 Кэширование ответов объединяет профили кэша, условные правила, динамические ключи кэша и параметры переопределения стандарта в единой модели управления vService.
Наш подход
TR7 управляет поведением кэша через четыре слоя: профили, условия, динамические ключи и управляемые переопределения.
Именованные профили кэша обеспечивают квоты на уровне сервиса
Профиль кэша объединяет имя, размер, TTL, настройки ETag и отладочного заголовка в одном месте. Один и тот же профиль может использоваться несколькими vService, при этом каждый сервис управляется собственными ограничениями кэша.
Условные правила кэша принимают решения на уровне эндпоинта
Каждое правило кэша привязывается к пути, методу, заголовку, cookie или другим переменным через движок условий FX. Публичный каталог на том же backend может кэшироваться, пока корзина пользователя исключена — без изменения какого-либо кода приложения.
Динамические ключи кэша предотвращают ответы с неверным контентом
Страна, тип устройства, идентификатор тенанта, сегмент пользователя или пользовательский заголовок могут быть добавлены в ключ кэша. Один и тот же URL разделяется на отдельные слоты кэша в зависимости от контекста, сохраняя быстродействие кэша при одновременном повышении корректности контента.
Опции переопределения стандарта повышают эффективность кэша
Проверки хоста, строки запроса, заголовка запроса и заголовка ответа могут быть намеренно обойдены. Неправильно настроенные backend или параметры отслеживания больше не подавляют коэффициенты попаданий. Операторы явно решают, какой стандарт переопределить и когда.
Возможности
Кэширование ответов делает каждое поведение — от профиля кэша до динамического ключа — настраиваемым на уровне vService.
Именованные профили кэша централизуют конфигурацию размера и TTL
Каждый профиль определяется именем, максимальным размером и временем ожидания. Ограничение размера контролирует использование кэша на уровне сервиса. Время ожидания настраивается в секундах, минутах или часах. Применение одного профиля к нескольким vService снижает операционное дублирование.
Попадание и промах кэша видны через заголовок ответа
TR7 может добавлять отладочный заголовок к ответам, позволяя разработчику или оператору видеть на панели Network браузера, пришёл ли ответ из кэша или от backend. Никакой дополнительный инструмент логирования не нужен для быстрой проверки — это ускоряет ввод в эксплуатацию и настройку.
Список условных правил кэша обеспечивает управление на уровне эндпоинта
В рамках одного профиля кэша может быть определено несколько правил. Каждое правило активируется путём, методом, заголовком, cookie или условиями FX. `/assets/*` может кэшироваться на длительное время, пока `/api/cart` исключён. Различные поведения кэша в рамках одного vService управляются из единой панели.
Поддержка ETag исключает ненужную передачу данных
ETag может быть включён для каждого правила. Когда клиент повторно запрашивает один и тот же объект и контент не изменился, он получает ответ с валидацией вместо полного тела. Это сокращает потребление полосы пропускания и особенно эффективно для статических ресурсов и редко изменяющихся ответов API.
Динамические ключи кэша создают отдельные слоты для каждого контекста
Когда динамическое кэширование включено, в ключ кэша могут добавляться пользовательские переменные. Страна, тип устройства, идентификатор тенанта, группа A/B-тестирования или значение, извлечённое из JWT, — всё это может стать частью ключа. Один и тот же URL чисто разделяется по контекстам. Это делает кэширование практичным для современных сценариев API и SaaS.
Игнорирование хоста объединяет многодоменный контент в один слот кэша
Когда один и тот же backend отдаёт идентичный контент под несколькими доменами, хост может быть исключён из ключа кэша. Домены типа `a.example` и `b.example` могут разделять один и тот же кэшированный объект, снижая дублирование кэша. Эту опцию следует использовать только тогда, когда контент действительно общий.
Игнорирование строки запроса не позволяет параметрам отслеживания нарушить кэш
`utm_source`, коды кампаний и аналитические параметры могут заставить один и тот же контент выглядеть как разные объекты. При активном игнорировании строки запроса эти параметры исключаются из ключа кэша. Одна и та же страница под несколькими вариантами параметров отслеживания больше не обращается к backend повторно. Коэффициенты попаданий для публичного контента заметно улучшаются.
Игнорирование проверки запроса ограничивает обход кэша на стороне клиента
Некоторые клиенты или боты добавляют заголовки, пытающиеся обойти кэширование при каждом запросе. Игнорирование проверки запроса позволяет намеренно игнорировать это поведение. Статический контент и публичные ответы API защищены от ненужной нагрузки на backend. Эту настройку следует применять с осторожностью на чувствительных с точки зрения безопасности эндпоинтах.
Игнорирование проверки ответа может переопределять неправильно настроенные заголовки backend
Backend может ошибочно отправлять `no-store` или излишне ограничительные заголовки кэша. Игнорирование проверки ответа позволяет операторам намеренно обходить эти заголовки. Преимущества кэша достигаются без изменения кода приложения. Эту опцию следует использовать только для детерминированных и безопасных ответов.
Кэширование всех методов поддерживает сценарии GraphQL POST
Стандартное поведение HTTP-кэша фокусируется на ответах GET и HEAD. TR7 позволяет операторам включать в область кэша ответы POST. Это особенно полезно, когда запросы GraphQL поступают через POST. Хеш тела или соответствующие переменные FX могут быть добавлены в ключ кэша для обеспечения безопасного разделения.
Кэш на основе памяти управляется через мягкую перезагрузку
Кэш хранится в памяти во время выполнения. Изменения конфигурации применяются через модель мягкой перезагрузки; никакой эндпоинт инвалидации во время выполнения не заявлен. Обновление профиля кэша или правила обновляет соответствующее поведение кэша. При перезапуске устройства кэш начинает прогреваться заново с нуля.
Наименее недавно использованные объекты вытесняются автоматически
При достижении ограничения размера кэша наименее используемые или устаревшие объекты вытесняются. Операторам не нужно управлять отдельными объектами вручную. Ограничение размера предотвращает влияние кэша одного vService на другие сервисы. Размер профиля может быть увеличен для больших каталогов ресурсов.
Операционная глубина
Кэширование ответов следует планировать совместно с TTL кэша, размером объекта, дизайном ключа, моделью инвалидации и границами безопасности.
Размер кэша
Максимальный размер для профиля кэша определяется в МБ; поддерживается до 2048 МБ на профиль. Большие профили подходят для обширных каталогов ресурсов; более низкий предел достаточен для небольших кэшей ответов API.
Минимальное время ожидания
Очень короткое TTL вызывает перегрузку кэша и снижает пользу от кэширования. TR7 устанавливает минимум 10 секунд для предотвращения ненужных циклов заполнения-опустошения. TTL должно настраиваться в соответствии с частотой обновления каждого эндпоинта.
Безопасность ключа кэша
Плохо спроектированный ключ кэша может возвращать специфичный для пользователя или тенанта контент в неправильном контексте. Когда необходима дифференциация по тенанту, стране, типу устройства или сегменту пользователя, эти значения должны быть включены в динамические ключи кэша. Чувствительные эндпоинты по умолчанию должны быть исключены из кэширования.
Поведение при перезапуске
Кэш основан на памяти; при перезапуске устройства или сервиса он начинается пустым. Это устраняет сложность постоянного дискового кэша. Кэш снова прогревается с начальной волной трафика.
Обновление на основе правил
Никакой эндпоинт инвалидации во время выполнения не заявлен. Поведение кэша управляется редактированием профилей или правил и запуском мягкой перезагрузки. Чтобы изменить поведение конкретного эндпоинта, обновите соответствующее правило кэша.
Аудит и операции
Изменения профиля кэша, времени ожидания, опций игнорирования и динамических ключей должны фиксироваться в журнале аудита. Видно, кто изменил поведение кэша для какого эндпоинта. Это особенно важно для соответствия нормативам и анализа инцидентов.
Когда применять
Кэширование каталогов продуктов e-commerce по стране
Страницы продуктов и API каталогов кэшируются на определённый период. Страна добавляется в ключ кэша, чтобы рынки с разными ценами или уровнями запасов получали правильный контент.
Краткосрочное кэширование публичных ответов API
Эндпоинты новостей, объявлений или публичного контента могут кэшироваться на несколько минут. Игнорирование строки запроса предотвращает снижение коэффициента попаданий параметрами отслеживания.
Изоляция на уровне тенанта для мультитенантного SaaS-контента
Идентификатор тенанта или пользовательский заголовок добавляется в ключ кэша. Один и тот же путь безопасно направляется в отдельные слоты кэша для разных тенантов.
Управляемое кэширование ответов GraphQL POST-запросов
Даже когда запросы GraphQL поступают через POST, детерминированные запросы могут кэшироваться. Хеш тела или соответствующие переменные FX добавляются в ключ кэша, чтобы минимизировать риск возврата неверного ответа.
Разгрузка трафика статических ресурсов с backend
CSS, JS, изображения и шрифты кэшируются с длительным TTL. При активном ETag клиенты пропускают загрузку полного тела при запросе неизменённого контента.
Отдельный кэш рендеринга для мобильных и настольных устройств
Семейство User-Agent или класс устройства добавляется в ключ кэша. Один и тот же URL хранится в отдельных слотах кэша для мобильных и настольных устройств.
Часто задаваемые вопросы
Как стандартные заголовки, такие как Cache-Control и ETag, работают с TR7?
В чём разница между динамическими ключами кэша и заголовком Vary?
Можно ли кэшировать одни эндпоинты и исключать другие в рамках одного vService?
Как работает инвалидация кэша — есть ли runtime API?
Можно ли кэшировать ответы GraphQL POST?
Каковы рекомендуемые значения для размера кэша и времени ожидания?
Снизьте нагрузку на backend с помощью кэширования ответов
Профили кэша, условные правила, динамические ключи и RFC-совместимые опции переопределения для кэширования ответов. Давайте разберём живую настройку на ваших собственных сервисах.