← Cloudflare Workers / workers / reference

Как работает кеш

Workers были спроектированы и построены поверх глобальной сети Cloudflare, чтобы дать разработчикам прямой доступ к кэшу Cloudflare. Кэш обеспечивает временное хранилище на уровне дата-центра, что удобно для частого обращения к статическому или динамическому контенту.

Позволяя разработчикам записывать данные в кеш, Workers дают возможность настраивать поведение кеша в CDN Cloudflare. Чтобы узнать больше о преимуществах кеширования, ознакомьтесь со статьёй Learning Center о Что такое кеширование? ↗.

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

Концептуально есть два способа взаимодействовать с кешем Cloudflare через Worker:

• Вызов fetch() в скрипте Workers. Запросы, проксируемые через Cloudflare, кешируются даже без Workers согласно поведению зоны по умолчанию или настроенному поведению (например, статические ресурсы, такие как файлы с расширением .jpg кешируются по умолчанию). Workers могут дополнительно настроить это поведение следующим образом:

  • Настройка правил кеширования Cloudflare (то есть работа с cf объект запрос).

• Сохраняйте ответы с помощью Cache API из скрипта Workers. Это позволяет кешировать ответы, которые не были получены с источника, а также даёт более точный контроль благодаря:

  • Настройка поведения кеша для любого ресурса с помощью заголовков, таких как Cache-Control к ответу, переданному в cache.put().

  • Кеширование ответов, которые генерирует сам Worker, через cache.put().

При использовании точечной очистки кэша для ресурсов, кэшированных Worker, не очищайте URL конечного пользователя. Вместо этого очищайте URL, указанный в fetch запрос. Например, у вас есть Worker, который выполняется на https://example.com/hello и этот Worker выполняет fetch запрос к https://notexample.com/hello.

Что касается кеша, ресурс в fetch запрос (https://notexample.com/hello) это ресурс, который кешируется. Чтобы очистить его из кеша, нужно очистить https://notexample.com/hello.

Очистка URL конечного пользователя, https://example.com/hello, не сработает, потому что это не тот URL, который видит cache. Вам нужно проверить в своём Worker, какой URL вы на самом деле запрашиваете, чтобы можно было очистить нужный ресурс.

В предыдущем примере https://notexample.com/hello не проксируется через Cloudflare. Если https://notexample.com/hello проксировался (с оранжевым облаком) через Cloudflare, вам необходимо владеть notexample.com и очистить https://notexample.com/hello из notexample.com зону.

Чтобы лучше понять пример, изучите следующую диаграмму:

flowchart TD
accTitle: Single file purge  assets cached by a worker
accDescr: This diagram is meant to help choose how to purge a file.
A("You have a Worker script that runs on <code>https://</code><code>example.com/hello</code> <br> and this Worker makes a <code>fetch</code> request to <code>https://</code><code>notexample.com/hello</code>.") --> B(Is <code>notexample.com</code> <br> an active zone on Cloudflare?)
    B -- Yes --> C(Is <code>https://</code><code>notexample.com/</code> <br> proxied through Cloudflare?)
    B -- No  --> D(Purge <code>https://</code><code>notexample.com/hello</code> <br> from the original <code>example.com</code> zone.)
    C -- Yes --> E(Do you own <br> <code>notexample.com</code>?)
    C -- No --> F(Purge <code>https://</code><code>notexample.com/hello</code> <br> from the original <code>example.com</code> zone.)
    E -- Yes --> G(Purge <code>https://</code><code>notexample.com/hello</code> <br> from the <code>notexample.com</code> zone.)
    E -- No --> H(Sorry, you can not purge the asset. <br> Only the owner of <code>notexample.com</code> can purge it.)

Ресурсы, сохранённые в кеше через Cache API операции можно очистить несколькими способами:

• Вызовите cache.delete внутри Worker, чтобы сбросить кэш для ресурса с соответствующей переменной запроса.

  • Ресурсы, очищенные таким образом, удаляются из кеша только в том дата-центре, где выполнялась среда выполнения Worker.

• Чтобы очистить ресурс глобально, используйте стандартный варианты очистки кеша. Из-за особенностей реализации Cache API не все endpoint для очистки кеша работают для ресурсов, сохранённых через Cache API.

  • Все ресурсы зоны можно удалить из кэша с помощью Полная очистка операция кеширования. Такая очистка удалит из кеша во всех дата-центрах все ресурсы, связанные с зоной Cloudflare, независимо от установленного метода.

  • Cache Tags можно динамически добавлять к запросам в Worker, вызывая response.headers.append() и добавление Cache-Tag значения этому запросу динамически. После установки эти теги можно использовать для выборочной очистки ресурсов из кэша без аннулирования всех кэшированных ресурсов зоны.

• В настоящее время невозможно очистить кеш по URL, для которого Worker задал собственный ключ кеша. Вместо этого используйте пользовательский ключ, созданный с помощью Cache Rules. Также можно очистить ресурсы с помощью таких методов, как полная очистка, очистка по тегу, очистка по имени хоста или очистка по префиксу.

Кэш браузера управляется через Cache-Control заголовок, отправляемый в ответе клиенту ( Response экземпляр, возвращаемый обработчиком). Worker может настраивать поведение кеша браузера, задав этот заголовок в ответе.

К другим способам управления кэшем Cloudflare, не описанным в этой документации, относятся Page Rules и настройки кэша Cloudflare. Подробнее см. Как настроить кеш Cloudflare если хотите избежать написания JavaScript, сохранив при этом определённую детализацию управления.

В контексте Workers fetch предоставляемый средой выполнения, взаимодействует с кешем Cloudflare. Сначала fetch проверяет, соответствует ли URL другой зоне. Если это так, он читает через кэш (или Worker) этой зоны. В противном случае он читает через кэш собственной зоны, даже если URL относится к сайту, не использующему Cloudflare. Настройки кэша для fetch автоматически применяют правила кеширования на основе ваших настроек Cloudflare. fetch не позволяет изменять или проверять объекты до того, как они попадут в кеш, но позволяет изменить то, как они будут кешироваться.

Когда ответ попадает в кэш, заголовок ответа содержит CF-Cache-Status: HIT. Понять, что объект пытается выполнить кеширование, можно по наличию CF-Cache-Status вообще.

Это шаблон показывает способы настройки поведения кеша Cloudflare для конкретного запроса с помощью fetch.

Cache API можно рассматривать как временное хранилище ключей и значений, где Request объект (точнее, URL запроса) является ключом, а Response это значение.

Для Cloudflare Cache доступны два типа пространств имён кеша:

• caches.default : вы можете обращаться к кешу по умолчанию (тому же кешу, что общий с fetch запросы), обратившись к caches.default. Это полезно, когда нужно переопределить уже закешированный контент после получения ответа.
• caches.open() : вы можете обращаться к именованному кешу (отдельному от кеша, общего с fetch запросы), используя let cache = await caches.open(CACHE_NAME). Обратите внимание, что caches.open ↗ представляет собой асинхронную функцию, в отличие от caches.default.

Когда использовать Cache API:

• Если вам нужно программно сохранять и (или) удалять ответы из кэша. Например, допустим, origin отвечает с Cache-Control: max-age:0 заголовок и не может быть изменён. Вместо этого вы можете клонировать Response, измените заголовок на max-age=3600 значение, а затем используйте Cache API, чтобы сохранить измененный Response в течение часа.

• Если вам нужно программно получить Response из кэша, не полагаясь на fetch запрос. Например, вы можете проверить, не закешировали ли вы уже Response для https://example.com/slow-response эндпоинт. Если это так, вы можете избежать медленного запроса.

Это шаблон показывает способы использования Cache API. Об ограничениях Cache API см. Лимиты.

• Cache API
• Настройка поведения кеша с помощью Workers