Kešuokite duomenis, kurie yra brangūs gaminti, skaitomi dažnai ir retai keičiasi — čia kešavimas atnešti didžiausią naudą. TTL (gyvavimo laikas) yra kompromis tarp aktualumo (kiek šviežūs duomenys turi būti) ir pasenimo tolerancijos (kiek netikslūs duomenys gali būti ir kiek laiko).
Geras kešo kandidatas turi aukštą vertę visuose trijuose aspektuose:
Nekešuokite pigu skaičiuoti, rašyti imlią, arba per vartotoją slaptos informacijos, kurios aktualumas turi būti tikslus (pvz., sąskaitos likutis atliekant operaciją).
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
Dėl korektišku darbo su duomenimis, kurie keičiasi nenumatytu būdu, kombinuokite TTL su aiškiu invalidavimu: rašyk-per-kešą arba trink-rašant, kad kešas būtų iš karto panaikintas, kai šaltinis pasikeičia, užuot laukus pabaigos.
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
Stebėkite kešo pataikymo santykį, kad suderintumėte TTL: žemas santykis reiškia, kad beveik nekešuojate; aukštas santykis su pasenimo skundais reiškia, kad TTL yra per ilgi.
Teisingas ką-kešuoti ir TTL nustatymas yra efektyvaus kešavimo šerdis. Kešavę neteisingus dalykus, pridėsite sudėtingumo be naudos; TTL nustatyti per ilgai — pateisite pasenusius duomenis; per trumpai — prarasite naudą. Naudodami pasenimo toleranciją TTL pasirinkimui, pridėdami aiškų invalidavimą korektuvimui ir stebėdami pataikymo santykį, gausite principingą, išmatuojamą būdą kešavimui.