Helyezz a gyorsítótárba olyan adatokat, amelyek drágák előállítani, gyakran olvasnak, és ritkán változnak — itt kamatozódik a legjobban a gyorsítótárazás. A TTL (time to live) a frissesség (mennyire aktuálisak az adatok) és az elavultság tolerancia (mennyire lehetnek rosszak és meddig) közötti kompromisszum.
Jó gyorsítótár-jelölt magas pontot kap mindhárom kritériumban:
Ne gyorsítótárazz olcsón számítható, írás-intenzív vagy felhasználónkénti titkos adatokat, amelyeknek pontosnak kell lenniük (pl. számlaegyenleg egy tranzakció pillanatában).
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
A kiszámíthatóan változó adatok helyessége érdekében kombináld a TTL-t explicit invalidálással: write-through vagy delete-on-write, hogy a gyorsítótár azonnal üresedjen, amikor a forrás változik, ahelyett, hogy lejáratra várnál.
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
Figyelj a cache hit ratio-ra a TTL-ek finomhangolásához: az alacsony arány azt jelenti, hogy alig gyorsítótárazol; a magas arány elavultság panaszokkal azt jelenti, hogy a TTL-ek túl hosszúak.
A helyes gyorsítótárazási döntések és a TTL az effektív gyorsítótárazás lényege. Ha rosszul választod meg, ami gyorsítótárban van, összetettséget adsz hozzá haszon nélkül; a TTL túl hosszú beállítása elavult adatokat szolgáltat; túl rövid és elveszted az előnyt. Az elavultság toleranciájának felhasználásával a TTL kiválasztásához, az explicit invalidálás hozzáadásához az helyességhez, és a hit arány figyelésével egy alapelven alapuló, mérhető módja van a gyorsítótárazásnak.
IT interjúkérdések gyűjteménye részletes válaszokkal — Juniortól Seniorig.
Adományozás