Požadavek prochází více vrstvami cache, z nichž každá je blíže uživateli a slouží rychleji, ale obsahuje méně dat. Myšlenka je odpovědět co nejdál (blíže klientu) a pouze se vrátit k původu, když žádná upstream vrstva nemůže odpověď poskytnout.
Browser → CDN → Reverse proxy → App/object cache → OPcache → Database
(closest to user, fastest) (closest to data)
Cache-Control/ETag; assety často mají dlouhé TTL (dny–rok) s hasovanými jmény souborů.for each layer outward → inward:
if layer has fresh copy → return it (stop here) // a hit; cheapest possible
else → ask the next layer in // a miss; falls through
origin (app + DB) → does the real work, fills caches on the way back out
Každá vrstva si vyměňuje čerstvost za rychlost: vnější vrstvy jsou nejrychlejší, ale nejspíš zastaralé, takže umisťujte dlouhé TTL + hashing obsahu na skutečně statické věci a krátké TTL + invalidaci na dynamické.
Většina latence a snížení zátěže ve web stacku pochází z cachování na správné vrstvě. Vědět, co jednotlivá vrstva drží a jaké má typické TTL, vám umožní umístit cache tam, kde skutečně pomáhá, vyhnout se podávání zastaralých dat a zdůvodnit, proč se změna nezobrazila (která vrstva stále poskytuje starou kopii).
Knihovna IT otázek k pohovoru s podrobnými odpověďmi — od Junior po Senior.
Přispět