Välimuistoi data, joka on kallista tuottaa, luetaan usein ja muuttuu harvoin — siellä välimuistintaminen kannattaa eniten. TTL (eliniäksi) on kompromissi tuoreuden (kuinka ajankohtaisia tietojen on oltava) ja vanhenemisen sietokyvyn (kuinka vääriä ne voivat olla ja kuinka kauan) välillä.
Hyvä välimuistiehdokas saa korkeat pisteet kaikissa kolmessa:
Älä välimuistoi halpojen laskentaa, paljon kirjoitettavia tai käyttäjäkohtaisia salaisuustietoja, joiden tuoreuden on oltava tarkka (esim. tilin saldot liiketoimen hetkellä).
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
Tiedoille, jotka muuttuvat arvaamattomasti, yhdistä TTL eksplisiittisen mitätöinnin kanssa: write-through tai delete-on-write, jotta välimuisti tyhjennettään silloin kun lähde muuttuu vanhenemisen odottamisen sijaan.
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
Seuraa välimuistin osumien suhdetta TTL:ien säätämiseksi: alhainen suhde tarkoittaa, että et lähes välimuistoi; korkea suhde vanhentuneisuusvalituksilla tarkoittaa, että TTL:t ovat liian pitkiä.
Oikean välimuistinnettavan ja TTL:n saaminen on tehokkaan välimuistinnuksen ydin. Välimuistoi väärät asiat ja lisäät monimutkaisuutta ilman voittoa; aseta TTL:t liian pitkiksi ja palvelet vanhentunutta dataa; liian lyhyiksi ja menetät hyödyn. Vanhenemisen sietokyvyn käyttö TTL:ien valintaan, eksplisiittisen mitätöinnin lisääminen oikeellisuudelle ja osumien suhteen seuranta antaa sinulle periaatteellisen, mitattavan tavan välimuistintaa.