← Cloudflare Workers / workers / reference

Jak funguje mezipaměť

Workers byly navrženy a vytvořeny nad globální sítí Cloudflare tak, aby vývojářům umožnily přímo pracovat s cache Cloudflare. Cache může poskytovat dočasné úložiště lokální pro dané datové centrum, což je praktický způsob, jak často přistupovat ke statickému nebo dynamickému obsahu.

Tím, že vývojářům umožňují zapisovat do cache, poskytují Workers způsob, jak přizpůsobit chování cache v CDN Cloudflare. Chcete-li se dozvědět více o výhodách ukládání do cache, přečtěte si článek v Learning Center o Co je ukládání do mezipaměti? ↗.

Cloudflare Workers se spouštějí před cache, ale lze je využít i k úpravě assetů poté, co jsou vráceny z cache. Úprava assetů vrácených z cache umožňuje podepisovat nebo personalizovat odpovědi a zároveň snižuje zátěž origin serveru a latenci pro koncového uživatele tím, že se assety doručují z blízké lokality.

Koncepčně existují dva způsoby, jak pomocí Workeru pracovat s Cache Cloudflare:

• Volání fetch() ve skriptu Workers. Požadavky směrované přes Cloudflare se ukládají do mezipaměti i bez Workers podle výchozího nebo nakonfigurovaného chování zóny (například statické assety, tedy soubory končící na .jpg se ve výchozím nastavení ukládají do mezipaměti). Workers mohou toto chování dále přizpůsobit těmito způsoby:

  • Nastavování pravidel cache Cloudflare (tedy práce s cf objekt z požadavek).

• Ukládejte odpovědi pomocí Cache API ze skriptu Workeru. To umožňuje cachovat odpovědi, které nepocházejí z originu, a zároveň poskytuje jemnější kontrolu díky:

  • Přizpůsobení chování cache libovolného aktiva nastavením hlaviček, jako je Cache-Control na odpovědi předané do cache.put().

  • Ukládání odpovědí generovaných samotným Workerem do mezipaměti prostřednictvím cache.put().

Pokud pro vymazání prostředků uložených Workerem v mezipaměti používáte vymazání jednoho souboru, nevymazávejte URL adresu koncového uživatele. Místo toho vymažte URL adresu, která je uvedena v fetch požadavek. Máte například Worker, který běží na https://example.com/hello a tento Worker vytváří fetch požadavek na https://notexample.com/hello.

Pokud jde o mezipaměť, prostředek v fetch požadavek (https://notexample.com/hello) je prostředek, který se ukládá do mezipaměti. Chcete-li ho vyčistit, musíte vyčistit https://notexample.com/hello.

Vymazávání URL adresy koncového uživatele, https://example.com/hello, nebude fungovat, protože to není URL, kterou vidí mezipaměť. Ve svém Workeru musíte ověřit, kterou URL skutečně načítáte, abyste mohli vyčistit správný prostředek.

V předchozím příkladu https://notexample.com/hello neprochází přes proxy Cloudflare. Pokud https://notexample.com/hello byl proxován (s oranžovým mrakem) přes Cloudflare, musíte vlastnit notexample.com a vyprázdněte https://notexample.com/hello z notexample.com zóna.

Pro lepší pochopení příkladu se podívejte na následující diagram:

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.)

Assets uložené v mezipaměti prostřednictvím Cache API operace lze vymazat několika způsoby:

• Zavolejte cache.delete v rámci Workeru pro zneplatnění mezipaměti u prostředku s odpovídající proměnnou požadavku.

  • Assets takto vyčištěné z cache jsou odstraněny pouze lokálně, v datovém centru, kde běžel runtime Workeru.

• Chcete-li globálně vymazat asset z cache, použijte standardní možnosti vymazání cache. Vzhledem k implementaci Cache API nefungují pro čištění assetů uložených pomocí Cache API všechny endpointy pro čištění cache.

  • Všechna aktiva v zóně lze vymazat pomocí Purge Everything operace vymazání cache. Toto vymazání odebere z cache ve všech datacentrech všechna aktiva patřící k dané zóně Cloudflare bez ohledu na nastavenou metodu.

  • Cache Tags lze dynamicky přidat k požadavkům ve Workeru voláním response.headers.append() a připojením Cache-Tag hodnoty dynamicky danému požadavku. Jakmile jsou nastaveny, lze tyto tagy použít k selektivnímu purge assetů z cache, aniž by došlo k invalidaci všech assetů uložených v cache dané zóny.

• V současnosti není možné vymazat URL adresu, která používá vlastní cache key nastavený Workerem. Místo toho použijte vlastní klíč vytvořený pomocí Cache Rules. Prostředky můžete také vymazat pomocí funkcí purge everything, purge by tag, purge by host nebo purge by prefix.

Cache prohlížeče se řídí pomocí Cache-Control hlavička odeslaná v odpovědi klientovi (tato Response instance vrácená z handleru). Workers mohou přizpůsobit chování mezipaměti prohlížeče nastavením této hlavičky v odpovědi.

Mezi další způsoby ovlivnění mezipaměti Cloudflare, které tato dokumentace nepopisuje, patří Page Rules a nastavení cache Cloudflare. Více informací najdete v Jak přizpůsobit mezipaměť Cloudflare pokud se chcete vyhnout psaní JavaScriptu, a přesto si zachovat alespoň částečnou míru kontroly.

V kontextu Workers je fetch poskytovaná runtime komunikuje s cache Cloudflare. Nejprve fetch ověří, zda URL neodpovídá jiné zóně. Pokud ano, projde cache (nebo Worker) této zóny. V opačném případě projde cache vlastní zóny, a to i tehdy, pokud URL patří webu mimo Cloudflare. Nastavení cache na fetch automaticky uplatňuje pravidla ukládání do cache podle vašeho nastavení Cloudflare. fetch neumožňuje upravovat ani zkoumat objekty před tím, než se dostanou do mezipaměti, ale umožňuje upravit způsob jejich ukládání do mezipaměti.

Když odpověď naplní mezipaměť, hlavička odpovědi obsahuje CF-Cache-Status: HIT. Že se objekt pokouší o cachování, poznáte podle výskytu CF-Cache-Status vůbec.

Tento šablona ukazuje způsoby, jak upravit chování mezipaměti Cloudflare pro daný požadavek pomocí fetch.

Cache API si lze představit jako dočasné úložiště klíč-hodnota, kde Request objekt (přesněji řečeno URL požadavku) je klíč a Response je hodnota.

Pro Cloudflare Cache jsou k dispozici dva typy cache namespaces:

• caches.default : můžete přistupovat k výchozí mezipaměti (stejné mezipaměti sdílené s fetch požadavky) pomocí přístupu k caches.default. Hodí se to, když potřebujete přepsat obsah, který je již uložen v mezipaměti, po přijetí odpovědi.
• caches.open() : můžete přistupovat k mezipaměti s vlastním jmenným prostorem (oddělené od mezipaměti sdílené s fetch požadavky) pomocí let cache = await caches.open(CACHE_NAME). Vezměte na vědomí, že caches.open ↗ je asynchronní funkce, na rozdíl od caches.default.

Kdy použít Cache API:

• Pokud chcete programově ukládat nebo mazat odpovědi z mezipaměti. Řekněme například, že origin server odpovídá Cache-Control: max-age:0 hlavička a nelze ji změnit. Místo toho můžete klonovat Response, upravte hlavičku na max-age=3600 hodnota, a poté pomocí Cache API uložte upravenou Response po dobu jedné hodiny.

• Pokud chcete programově přistupovat k objektu Response z mezipaměti, aniž byste se spoléhali na fetch požadavek. Můžete si například ověřit, zda jste již do mezipaměti uložili Response pro https://example.com/slow-response koncový bod. Pokud ano, můžete se pomalému požadavku vyhnout.

Tento šablona ukazuje způsoby použití cache API. Limity cache API najdete v Limity.

• Cache API
• Přizpůsobení chování cache pomocí Workers