Ukládejte do mezipaměti data, která jsou nákladná na výrobu, často čtena a zřídka se mění — tam se caching vyplácí nejvíce. TTL (čas života) je kompromis mezi čerstvostí (jak aktuální musí být data) a tolerancí zastaralosti (jak dlouho a jak moc mohou být špatná).
Dobrý kandidát na mezipaměť se hodnotí vysoko ve všech třech ohledech:
Neukládejte do mezipaměti levné výpočty, data s velkým počtem zápisů nebo tajná data pro každého uživatele, kde musí být čerstvost přesná (např. zůstatky účtů v okamžiku transakce).
Staleness tolerance → TTL:
config / static reference data → long (hours to days)
product listings, article body → medium (minutes)
prices, stock, leaderboards → short (seconds)
must always be exact → don't cache, or use explicit invalidation
Pro správnost dat, která se mění nepředvídatelně, zkombinujte TTL s explicitní neplatností: write-through nebo delete-on-write tak, aby se mezipaměť vyčistila v okamžiku změny zdroje, místo čekání na vypršení.
on update(record):
db.save(record)
cache.delete(key(record)) // invalidate now, don't serve stale until TTL
hit ratio = hits / (hits + misses)
high (>90%) → cache is doing its job
low → TTL too short, keys too granular, or data not cacheable
Pozorujte poměr zásahů mezipaměti pro seřízení TTLs: nízký poměr znamená, že téměř nic neukládáte; vysoký poměr se stížnostmi na zastaralost znamená, že TTLs jsou příliš dlouhé.
Získání správného co-do-mezipaměti a TTL je základem efektivního cachingu. Cacheování nesprávných věcí přidává složitost bez zisku; nastavení TTLs příliš dlouhých vám slouží zastaralá data; příliš krátká a ztratíte výhodu. Použití tolerance zastaralosti pro výběr TTLs, přidání explicitní neplatnosti pro správnost a sledování poměru zásahů vám dává principiální, měřitelný způsob cachování.