TTL: vad är det, livslängd för cache och hur det fungerar

Vad är TTL?

TTL (Time To Live) — är en tidsstämpel eller ett intervall efter vilket data anses vara ogiltig. I samband med cachning avgör TTL hur länge en post kan lagras i cachen innan den måste hämtas igen från den ursprungliga källan. I nätverksprotokoll begränsar TTL livslängden för ett paket och förhindrar oändlig routning.

TTL-värdet uttrycks alltid i tidsenheter: millisekunder, sekunder, minuter eller timmar. Efter den inställda tiden tas posten antingen bort från cachen eller markeras som stale (föråldrad). Vid nästa begäran till en föråldrad post kan systemet returnera föråldrade data med efterföljande uppdatering (stale-while-revalidate) eller blockera begäran tills färska data har tagits emot.

Valet av TTL är alltid en kompromiss mellan aktualitet av data och prestanda. För kort TTL (1–5 sekunder) tvingar applikationen att ofta utföra nätverksbegäran, vilket upphäver fördelarna med cachning. För lång TTL (timmar/dagar) ökar risken att visa föråldrad information för användaren. Det optimala värdet beror på datatypen: växelkurser — sekunder, väder — minuter, API-version — timmar.

TTL och cache-invalidering

TTL är passiv invalidering: data tas automatiskt bort efter att tiden har löpt ut. Alternativet är aktiv invalidering, där datakällan meddelar cachen om ändringar (till exempel via WebSocket-meddelanden eller push-notiser). Passiv invalidering via TTL är enklare att implementera, men garanterar inte omedelbar aktualitet. Aktiv invalidering är mer komplex, men gör det möjligt att hålla data aktuella utan de fördröjningar som är karakteristiska för TTL.

Hur TTL fungerar

TTL-mekanismen kan implementeras på två sätt: absolut utgång (absolute expiration) och relativ utgång (relative expiration). Vid absolut utgång lagrar posten en specifik tidpunkt när den blir ogiltig. Vid relativ utgång registreras postens skapelsetid och TTL som ett intervall, och kontrollen utförs genom att beräkna creationTime + TTL > currentTime.

Vid varje begäran till cachen kontrollerar systemet TTL för varje post. Om TTL har löpt ut tas data bort eller markeras som stale, och begäran dirigeras till källan. För att optimera TTL-kontrollen kan scheduled-cleanup (periodisk borttagning av alla utgångna poster) eller lazy-cleanup (borttagning endast vid åtkomst till posten) användas. Lazy-cleanup är mer minneseffektivt eftersom det inte kräver en bakgrundstråd för att skanna hela cachen.

I distribuerade system används TTL även för automatisk konfliktlösning. Till exempel, om två servrar samtidigt har skrivit olika värden för samma nyckel, kan posten med senare TTL anses vara prioriterad. Amazon DynamoDB använder TTL för automatisk borttagning av föråldrade poster i tabeller — detta är en inbyggd funktion som inte kräver manuell hantering.

Strategier för läsning av föråldrade data

För att öka prestandan efter att TTL har löpt ut tillämpas strategier för läsning av föråldrade data. Stale-while-revalidate — returnera omedelbart föråldrade data till klienten och starta samtidigt en bakgrundsuppdatering. Stale-if-error — returnera föråldrade data om källan är tillfälligt otillgänglig. Cache-Aside (Lazy Loading) — vid cache-miss, ladda data från källan, spara i cachen med ny TTL och returnera först därefter till klienten. Varje strategi väljs baserat på kraven för datakonsistens.

TTL vid cachning av data

I mobila applikationer är TTL den viktigaste mekanismen för cachehantering. Låt oss titta på de viktigaste scenarierna där TTL bestämmer applikationens beteende och användarupplevelsen.

Cachning av HTTP-svar

HTTP-protokollet tillhandahåller en inbyggd TTL-mekanism via rubrikerna Cache-Control. Direktivet max-age anger TTL i sekunder: Cache-Control: public, max-age=3600 betyder att svaret kan cachas i 1 timme. Ytterligare direktiv s-maxage (för delade cacheminnen, t.ex. CDN) och stale-while-revalidate ger finare kontroll. Om TTL sammanfaller med expires-rubriken har max-age prioritet som modernare HTTP/1.1-standard.

Cachning av bilder

För bilder kan TTL nå flera dagar, eftersom innehåll sällan ändras. Mobila applikationer använder dock ofta en hybridmetod: kort TTL för förhandsvisningar (30 minuter — bildrutors aktualitet) och lång TTL för bilder i full storlek (7 dagar). Bilder med HTTP-rubriken Cache-Control: immutable bör inte begäras igen alls förrän TTL har löpt ut — detta är en optimering för statiska resurser som föreslås i RFC 8246. Sådana bilder cachas på operativsystemsnivå (URLCache, OkHttp Cache) utan applikationens medverkan.

TTL i nätverksprotokoll

I nätverk används TTL inte för cachning, utan för att begränsa paketens livslängd. Varje IP-paket innehåller ett TTL-fält (8 bitar) som minskas med 1 av varje router. När TTL når 0 kasseras paketet och ett ICMP Time Exceeded-meddelande skickas tillbaka till avsändaren. Detta förhindrar oändlig routning vid loopar i nätverket.

TTL i DNS

DNS-poster har en TTL som avgör hur länge resolvern (t.ex. ISP:ns DNS-cache) kan lagra posten utan att fråga den auktoritativa servern. Typiska värden: 300 sekunder (5 minuter) för poster med frekventa ändringar, 86400 sekunder (24 timmar) för stabila domäner. CDN-tjänster anger ofta låg TTL (60–300 sekunder) för snabb omdirigering av trafik vid fel, medan statiska domäner kan ha TTL upp till 7 dagar. Vid servermigrering rekommenderas att först sänka TTL till 60 sekunder (48 timmar före migreringen) så att ändringarna sprids snabbt.

TTL i sessioner och token

I mobila applikationer används TTL för att hantera sessioner och åtkomsttoken. JWT-token (JSON Web Tokens) innehåller fältet exp (utgångstid), som är en absolut Unix-tid för utgång. Efter utgång används refresh-token för att få en ny åtkomsttoken utan omautentisering. TTL för åtkomsttoken är vanligtvis 1–24 timmar, för refresh-token 7–30 dagar. Detta är en balans mellan säkerhet (kort TTL minskar risken för läckage) och användarupplevelse (lång TTL minskar frekvensen av återinloggningar).

Strategier för TTL-val

Valet av TTL är ett tekniskt beslut som beror på datatypen, SLA för aktualitet och kostnaden för en ny begäran. Låt oss titta på de viktigaste strategierna.

Fast TTL

Den enklaste metoden — alla poster har samma TTL. Till exempel, cacha alla API-svar i 5 minuter. Fördel: enkel implementering och förutsägbart beteende. Nackdel: tar inte hänsyn till olika ändringsfrekvens för olika datatyper. Fast TTL är motiverat för homogen data där alla poster har samma färskhet — till exempel, kryptovalutakurser på en börs.

Adaptiv TTL

TTL ändras dynamiskt beroende på databeteendet. Till exempel, om en post sällan uppdateras på servern ökar TTL; om den uppdateras ofta — minskar. Implementeringen kan använda HTTP-svarsrubriker: rubriken Age (hur många sekunder svaret redan har tillbringat i cachen) och rubriken Date gör det möjligt att beräkna återstående livslängd. Adaptiv TTL ger bättre hit-ratio, men kräver ytterligare logik på klienten.

TTL med probabilistisk utgång

Probabilistic Early Expiration (PEE) — en teknik där TTL väljs slumpmässigt inom ett givet intervall. Detta förhindrar ”hjordeffekten“ (thundering herd), när många begäran upphör samtidigt och alla klienter vänder sig till källan samtidigt. PEE är särskilt användbart för CDN och högt belastade cacheminnen: istället för en enhetlig TTL på 300 sekunder används ett slumpmässigt värde mellan 240 och 360 sekunder, vilket fördelar belastningen på källan jämnt.

TTL-kodexempel

Låt oss titta på implementeringen av en cache med TTL i Kotlin med absolut utgång. Varje post lagrar skapelsetiden och vid läsning kontrolleras om TTL har löpt ut.

class TtlCache<K, V>(
    private val defaultTtlMs: Long = 300000L
) {
    private data class Entry<V>(
        val value: V,
        val createdAt: Long = System.currentTimeMillis()
    )

    private val map = ConcurrentHashMap<K, Entry<V>>()

    fun get(key: K): V? {
        val entry = map[key] ?: return null
        if (isExpired(entry)) {
            map.remove(key)
            return null
        }
        return entry.value
    }

    fun put(key: K, value: V, ttlMs: Long = defaultTtlMs) {
        map[key] = Entry(value, createdAt = System.currentTimeMillis() + ttlMs)
    }

    private fun isExpired(entry: Entry<*>): Boolean {
        return System.currentTimeMillis() > entry.createdAt
    }

    fun cleanup() {
        map.entries.removeIf { isExpired(it.value) }
    }
}

Klassen Entry lagrar värdet och skapelsetiden + TTL (absolut utgång). Metoden get kontrollerar utgång vid varje åtkomst (lazy-cleanup) — utgångna poster tas endast bort vid försök att komma åt dem. Metoden cleanup kan anropas periodiskt från en bakgrundstråd för att ta bort alla föråldrade poster i batch. ConcurrentHashMap säkerställer trådsäkerhet utan att blockera hela cachen.

Exempel: TTL för cachning av API-svar på iOS

I iOS är det praktiskt att använda URLCache med inställningarna memoryCapacity och diskCapacity för cachning med TTL. URLCache stödjer dock inte individuell TTL för olika begäran. Låt oss titta på ett anpassat omslag för NSCache med TTL-stöd.

final class ApiResponseCache {
    private var cache = NSCache<NSString, CacheEntry>()

    func getResponse(for url: URL) -> Data? {
        guard let entry = cache.object(forKey: url.absoluteString as NSString)
            else { return nil }
        guard entry.expirationDate > Date() else {
            cache.removeObject(forKey: url.absoluteString as NSString)
            return nil
        }
        return entry.data
    }

    func storeResponse(data: Data, for url: URL, ttl: TimeInterval) {
        let entry = CacheEntry(data: data, expirationDate: Date().addingTimeInterval(ttl))
        cache.setObject(entry, forKey: url.absoluteString as NSString)
    }
}

final class CacheEntry: NSObject {
    let data: Data
    let expirationDate: Date
}

I denna implementering används NSCache som en trådsäker lagringsplats. CacheEntry innehåller Data och expirationDate. Vid get kontrolleras om tiden har löpt ut; om så är fallet — tas posten bort och nil returneras. TTL ställs in i sekunder via TimeInterval och kan vara olika för varje URL: typiska värden för API-svar är 120 sekunder för dynamiskt innehåll och 3600 för statisk data.