Jan Mikoláš
Slovník pojmů
Cache
Cache vrací připravený výsledek místo opakovaného dotazu do databáze nebo vzdálené služby. Její klíč, platnost a invalidace musí odpovídat datům.
Stručná definice
Dočasná kopie pro častější a levnější čtení.
Cache drží hodnotu, kterou už aplikace jednou získala nebo dopočítala. Další požadavek pak může dostat odpověď z paměti, lokálního souboru, reverse proxy nebo specializovaného úložiště dříve, než aplikace otevře databázové připojení či zavolá externí API. Takovému úspěšnému použití se říká cache hit; když klíč neexistuje nebo hodnota vypršela, nastane cache miss a aplikace musí hodnotu znovu získat.
Cache není druhá autoritativní databáze. Objednávka, cena, oprávnění nebo stav skladu mají svůj zdroj pravdy, obvykle relační databázi nebo jiný vlastnický systém. Cache jen zrychluje čtení jejich bezpečně definovaného pohledu. Jakmile se zdroj změní, aplikace musí počítat s tím, že cache může ještě chvíli vracet starší verzi, a musí určit, kde je takové zpoždění přijatelné.
K čemu se používá
Zrychlení opakované práce, ne zakrytí špatného dotazu
Cache dává smysl u dat, která se čtou výrazně častěji než mění nebo jejichž výpočet či načtení stojí měřitelný čas a prostředky.
- produktový katalog, strom kategorií nebo nastavení obchodu, které se mění méně často než čte
- výsledek nákladného agregačního dotazu pro administraci nebo přehled skladu
- odpověď externí služby s jasnou dobou použitelnosti, například seznam výdejních míst
- HTTP odpověď pro veřejný, stejný obsah, který není závislý na přihlášeném uživateli
- krátkodobé technické údaje, jako je konfigurace feature flagu nebo počet požadavků pro rate limiting
Praktický příklad
Katalog produktu podle obchodu, jazyka a měny
E-shop zobrazuje stejný produkt opakovaně, ale výsledek se liší podle obchodu, jazyka a měny. Cache klíč proto tyto hodnoty obsahuje. Při miss aplikace načte produkt z databáze, vytvoří veřejný read model a uloží jej na krátké TTL. Změna názvu nebo ceny následně smaže všechny relevantní varianty, aby další čtení nevzalo starý pohled.
Kód nepoužívá cache pro rozhodnutí, zda lze objednávku zaplatit nebo expedovat. Tyto operace pracují přímo s aktuálním stavem v databázi. Cache je zde jen optimalizací veřejného čtení produktu.
$key = sprintf('product:v3:%s:%s:%s', $store, $locale, $currency);
$product = $cache->get($key, function () use ($productId, $store, $locale, $currency): ProductView {
$view = $productViewRepository->find($productId, $store, $locale, $currency);
return $view ?? throw new ProductNotFound($productId);
}, ttl: 300);Jak funguje
Cache-aside: aplikace rozhoduje, kdy hodnotu číst a uložit
Běžný postup cache-aside nechává zdroj pravdy mimo cache. Aplikace nejprve hledá připravenou hodnotu a při miss ji vytvoří ze zdroje.
- Sestavení klíče Klíč popíše přesný pohled na data: verzi formátu, obchod, jazyk, měnu i filtr. Dva rozdílné výsledky nesmějí sdílet stejný klíč.
- Čtení z cache Při hitu aplikace ověří, že hodnota ještě existuje a odpovídá očekávanému formátu. Potom ji vrátí bez další práce se zdrojem.
- Miss a načtení zdroje Když hodnota chybí, aplikace načte autoritativní data nebo provede výpočet. Správnost výsledku nesmí záviset na tom, zda cache běží.
- Uložení s politikou platnosti Výsledek se uloží s TTL, tagem nebo verzí. Rozhodnutí určuje, jak dlouho je možné hodnotu bez další kontroly použít.
- Změna a invalidace Při změně produktu, ceny či konfigurace se relevantní klíč smaže nebo změní jeho verze. Další čtení pak hodnotu bezpečně dopočítá.
Důležité pojmy
Klíč, platnost a vlastník dat určují správné chování cache.
Výběr Redis, souborové cache, CDN nebo HTTP cache je až druhé rozhodnutí. Nejdříve je potřeba určit, co je možné vracet starší.
Cache hit, miss a hit rate
Hit znamená použití existující hodnoty, miss nutnost ji vytvořit. Hit rate pomáhá zhodnotit přínos, ale bez latence a dopadu na zdroj neříká, zda cache řeší skutečný problém.
TTL a expirace
Time to live omezuje maximální stáří hodnoty. Krátké TTL snižuje riziko zastarání, ale zvyšuje počet miss; dlouhé TTL šetří zdroj, ale zvyšuje nárok na aktivní invalidaci.
Vrstvy cache
Prohlížeč, CDN, nginx, PHP proces a Redis mohou cacheovat odlišné věci. Každá vrstva má vlastní klíč, pravidla sdílení a způsob, jak se změna projeví.
Cache stampede
Po expiraci oblíbeného klíče může mnoho požadavků současně spustit stejný nákladný výpočet. Pomáhá zámek, single-flight, krátká obnova před expirací nebo náhodné rozložení TTL.
Zdroj pravdy a fallback
Při výpadku cache musí aplikace vědět, zda bezpečně načte zdroj, vrátí omezený výsledek nebo požadavek odmítne. Cache nemá být jediným místem, kde existuje kritický stav.
Vztah k ostatním pojmům
Cache, databáze a HTTP hranice mají rozdílnou odpovědnost.
Dobře navržená cache respektuje vlastnictví dat a funguje společně s pozorováním provozu, ne jako neprůhledné zrychlení.
- Redis
- Často slouží jako sdílená aplikační cache s TTL. Neznamená to, že každá hodnota v Redisu je cache nebo že Redis nahrazuje relační zdroj pravdy.
- PostgreSQL
- Relační databáze bývá autoritativním místem pro objednávky a další business data. Cache pouze urychluje přesně vybraný pohled.
- API a nginx
- HTTP cache může obsloužit veřejnou odpověď ještě před aplikací. Personalizované odpovědi, autorizace a mutace vyžadují mnohem opatrnější pravidla.
- CI/CD
- Nasazení nové verze může změnit formát ukládané hodnoty. Klíč proto potřebuje verzi nebo bezpečný postup, který nesmí vyzvednout starší serializaci.
Výhody a omezení
Rychlejší odpověď výměnou za další stav a rozhodnutí.
Přínosy
- nižší latence a menší počet nákladných dotazů či externích volání
- ochrana databáze a integrační služby při opakovaném stejném čtení
- možnost doručit veřejný obsah blíže klientovi přes HTTP vrstvu
- oddělení drahého read modelu od kritické transakční změny
Rizika a chyby
- zastaralá cena, dostupnost nebo oprávnění vrácené z nevhodně zvoleného klíče
- cache key bez jazyka, tenanta či varianty uživatele míchá odlišné výsledky
- vypršení velkého počtu klíčů současně přetíží zdroj
- cache bez metrik a limitů jen přesune problém do jiné služby
- předčasná cache zakryje chybějící index nebo neefektivní databázový dotaz
Hranice použití
Cacheovat měřitelně drahé a bezpečně sdílené čtení.
Před zavedením cache je vhodné změřit opakované čtení a odstranit základní chybu: chybějící databázový index, N+1 dotaz, příliš velký payload nebo zbytečné externí volání. Cache řeší stabilní vzor čtení, ne každou pomalou odpověď.
Nevhodná je jako jediná obrana pro stav, který musí být při každém požadavku přesný: potvrzení platby, rezervace posledního kusu nebo serverová autorizace. I zde může urychlit pomocné údaje, ale konečné rozhodnutí musí ověřit autoritativní data a transakční pravidla.
Na co myslet
Popsat, měřit a pravidelně ověřovat platnost hodnot.
Každá cache položka potřebuje klíč, životnost a vlastníka invalidace.
- zahrnout do klíče všechny vstupy, které mohou změnit výsledek: tenant, jazyk, měnu, filtr i verzi formátu
- určit TTL podle skutečné přijatelné zastaralosti, ne náhodně vysokým číslem
- měřit hit rate, dobu vytvoření hodnoty, počet evictions a dopad na zdroj dat
- navrhnout ochranu proti stampede pro drahé a často čtené klíče
- testovat chování při miss, expiraci, invalidaci i nedostupném cache backendu
- neukládat do sdílené cache citlivý personalizovaný obsah bez jasného oddělení klíčem a přístupovou kontrolou
Časté otázky
Co cache zrychlí a co nemá rozhodovat
Je Redis vždy cache?
Ne. Redis lze použít pro cache, fronty, čítače, zámky i další krátkodobý stav. O tom, zda je hodnota cache, rozhoduje její vztah ke zdroji pravdy a možnost ji bezpečně znovu vytvořit.
Stačí nastavit TTL?
TTL omezuje stáří hodnoty, ale neříká, co se stane po změně ceny, oprávnění nebo konfigurace. U citlivějších dat je potřeba aktivní invalidace, verzování klíče nebo jiné pravidlo konzistence.
Má být cache před každým databázovým dotazem?
Ne. Nejprve má smysl posoudit frekvenci, cenu dotazu, správné indexy a přijatelnost zastaralosti. Cache u málo čteného nebo stále se měnícího údaje může přidat více složitosti než přínosu.
Co když cache vypadne?
Aplikace má mít rozhodnutý fallback: bezpečně načíst zdroj, vrátit omezený výsledek nebo požadavek odmítnout. Kritická data nesmí existovat jen v cache.
Jak pracuji s daty v praxi
Výkon řeším spolu s aktuálností dat a chováním při výpadku.
U e-shopů, API a integračních služeb navrhuji cache vedle databáze, front a provozních limitů tak, aby optimalizace nezměnila význam business operace.