TTL: mi ez, a gyorsítótár élettartama és hogyan működik

Mi az a TTL?

TTL (Time To Live) — egy időbélyeg vagy intervallum, amely után az adatok érvénytelennek számítanak. A gyorsítótárazás kontextusában a TTL meghatározza, hogy egy rekord mennyi ideig tárolható a gyorsítótárban, mielőtt újra le kellene kérni az eredeti forrásból. A hálózati protokollokban a TTL korlátozza a csomag élettartamát, megakadályozva a végtelen útválasztást.

A TTL értéket mindig időegységekben fejezzük ki: ezredmásodperc, másodperc, perc vagy óra. A beállított idő lejárta után a rekord vagy törlődik a gyorsítótárból, vagy stale (elavult) jelölést kap. A következő, elavult rekordra irányuló kérésnél a rendszer visszaadhatja az elavult adatokat egy későbbi frissítéssel (stale-while-revalidate), vagy blokkolhatja a kérést a friss adatok megérkezéséig.

A TTL választása mindig kompromisszum az adatok naprakészsége és a teljesítmény között. A túl rövid TTL (1–5 másodperc) gyakori hálózati kérések végrehajtására kényszeríti az alkalmazást, semmissé téve a gyorsítótárazás előnyeit. A túl hosszú TTL (órák/napok) növeli az elavult információk megjelenítésének kockázatát. Az optimális érték az adattípustól függ: valutaárfolyamok — másodpercek, időjárás — percek, API-verzió — órák.

TTL és a gyorsítótár érvénytelenítése

A TTL passzív érvénytelenítés: az adatok automatikusan törlődnek az idő lejárta után. Alternatíva az aktív érvénytelenítés, amikor az adatforrás értesíti a gyorsítótárat a változásokról (például WebSocket üzeneteken vagy push értesítéseken keresztül). A passzív érvénytelenítés a TTL-en keresztül egyszerűbb megvalósítani, de nem garantálja az azonnali naprakészséget. Az aktív érvénytelenítés összetettebb, de lehetővé teszi az adatok naprakész állapotban tartását a TTL-re jellemző késleltetések nélkül.

Hogyan működik a TTL

A TTL mechanizmus kétféleképpen valósítható meg: abszolút lejárat (absolute expiration) és relatív lejárat (relative expiration). Az abszolút lejáratnál a rekord tárolja azt a konkrét időpontot, amikor érvénytelen lesz. A relatív lejáratnál a rekord létrehozási ideje és a TTL intervallumként kerül rögzítésre, az ellenőrzés pedig a creationTime + TTL > currentTime kiszámításával történik.

Minden, a gyorsítótárhoz intézett kérésnél a rendszer ellenőrzi az egyes rekordok TTL-értékét. Ha a TTL lejárt, az adatok törlődnek vagy stale jelölést kapnak, és a kérés a forráshoz irányítódik. A TTL-ellenőrzés optimalizálásához használható scheduled-cleanup (az összes lejárt rekord időszakos törlése) vagy lazy-cleanup (törlés csak a rekord elérésekor). A lazy-cleanup memóriahatékonyabb, mivel nem igényel háttérszálat a teljes gyorsítótár beolvasásához.

Az elosztott rendszerekben a TTL-t az automatikus konfliktusmegoldáshoz is használják. Például, ha két szerver egyszerre különböző értékeket írt ugyanahhoz a kulcshoz, a későbbi TTL-lel rendelkező rekord elsőbbséget élvezhet. Az Amazon DynamoDB a TTL-t használja az elavult rekordok automatikus eltávolítására a táblákból — ez egy beépített funkció, amely nem igényel kézi kezelést.

Elavult adatok olvasási stratégiái

A TTL lejárta utáni teljesítmény növeléséhez elavult adatok olvasási stratégiáit alkalmazzák. Stale-while-revalidate — azonnal add vissza az elavult adatokat az ügyfélnek, és ezzel egyidejűleg indíts háttérfrissítést. Stale-if-error — add vissza az elavult adatokat, ha a forrás átmenetileg nem érhető el. Cache-Aside (Lazy Loading) — gyorsítótár-hiba esetén töltsd be az adatokat a forrásból, mentsd el a gyorsítótárba új TTL-lel, és csak azután add vissza az ügyfélnek. Az egyes stratégiákat az adatok konzisztenciájára vonatkozó követelmények alapján válasszák ki.

TTL az adatok gyorsítótárazásában

A mobilalkalmazásokban a TTL a gyorsítótár-kezelés kulcsmechanizmusa. Tekintsük át azokat a fő forgatókönyveket, ahol a TTL meghatározza az alkalmazás viselkedését és a felhasználói élményt.

HTTP-válaszok gyorsítótárazása

A HTTP protokoll beépített TTL mechanizmust biztosít a Cache-Control fejléceken keresztül. A max-age direktíva másodpercekben adja meg a TTL-t: a Cache-Control: public, max-age=3600 azt jelenti, hogy a válasz 1 óráig gyorsítótárazható. A további direktívák, mint az s-maxage (megosztott gyorsítótárakhoz, pl. CDN) és a stale-while-revalidate finomabb vezérlést tesznek lehetővé. Ha a TTL egybeesik az expires fejléccel, a max-age élvez elsőbbséget, mint modernebb HTTP/1.1 szabvány.

Képek gyorsítótárazása

A képek esetében a TTL elérheti a több napot is, mivel a tartalom ritkán változik. A mobilalkalmazások azonban gyakran hibrid megközelítést használnak: rövid TTL az előnézetekhez (30 perc — képkockák naprakészsége) és hosszú TTL a teljes méretű képekhez (7 nap). A képek HTTP Cache-Control: immutable fejléccel egyáltalán nem kérhetők újra a TTL lejártáig — ez a statikus erőforrások optimalizálása, amelyet az RFC 8246 javasol. Az ilyen képek az operációs rendszer szintjén (URLCache, OkHttp Cache) kerülnek gyorsítótárazásra az alkalmazás részvétele nélkül.

TTL a hálózati protokollokban

A hálózatokban a TTL-t nem gyorsítótárazásra, hanem a csomagok élettartamának korlátozására használják. Minden IP-csomag tartalmaz egy TTL mezőt (8 bit), amelyet minden útválasztó 1-gyel csökkent. Amikor a TTL eléri a 0-értéket, a csomag eldobásra kerül, és a feladó ICMP Time Exceeded üzenetet kap. Ez megakadályozza a végtelen útválasztást a hálózati hurkok esetén.

TTL a DNS-ben

A DNS-rekordok TTL-je meghatározza, hogy a resolver (például az ISP DNS gyorsítótára) mennyi ideig tárolhatja a rekordot anélkül, hogy a hiteles szerverhez fordulna. Tipikus értékek: 300 másodperc (5 perc) a gyakran változó rekordokhoz, 86400 másodperc (24 óra) a stabil tartományokhoz. A CDN-szolgáltatások gyakran alacsony TTL-t (60–300 másodperc) állítanak be a forgalom gyors átirányításához meghibásodás esetén, míg a statikus tartományok TTL-je akár 7 nap is lehet. Szerver migrálásakor ajánlott előszőr 60 másodpercre csökkenteni a TTL-t (48 órával a migráció előtt), hogy a változások gyorsan terjedjenek.

TTL a munkamenetekben és tokenekben

A mobilalkalmazásokban a TTL-t a munkamenetek és hozzáférési tokenek kezelésére használják. A JWT tokenek (JSON Web Tokens) tartalmazzák az exp mezőt (lejárati idő), amely egy abszolút Unix-időbélyeg a lejáráshoz. A lejárás után a frissítő token (refresh token) szolgál új hozzáférési token beszerzésére újra hitelesítés nélkül. A hozzáférési token TTL-je általában 1–24 óra, a frissítő token TTL-je 7–30 nap. Ez egyensúly a biztonság (a rövid TTL csökkenti a szivárgás kockázatát) és a felhasználói élmény (a hosszú TTL csökkenti az újrabejelentkezések gyakoriságát) között.

TTL választási stratégiák

A TTL választása mérnöki döntés, amely függ az adattípustól, a naprakészségre vonatkozó SLA-tól és az újrakérés költségétől. Tekintsük át a fő stratégiákat.

Fix TTL

A legegyszerűbb megközelítés — minden rekord azonos TTL-lel rendelkezik. Például az összes API-válasz gyorsítótárazása 5 percig. Előny: egyszerű megvalósítás és kiszámítható viselkedés. Hátrány: nem veszi figyelembe a különböző adattípusok eltérő változási gyakoriságát. A fix TTL homogén adatoknál indokolt, ahol az összes rekord azonos ‛frissességgel” rendelkezik — például a kriptovaluták árfolyama egyetlen tőzsdén.

Adaptív TTL

A TTL dinamikusan változik az adatok viselkedésétől függően. Például, ha egy rekordot ritkán frissítenek a szerveren, a TTL nő; ha gyakran frissítik — csőkken. A megvalósítás használhatja a HTTP-válasz fejléceit: az Age fejléc (hány másodpercet töltött már a válasz a gyorsítótárban) és a Date fejléc lehetővé teszik a hátralévő élettartam kiszámítását. Az adaptív TTL jobb hit-ratiót biztosít, de többletlogikát igényel az ügyfél oldalán.

TTL valószínűségi lejárattal

Probabilistic Early Expiration (PEE) — olyan technika, ahol a TTL egy adott tartományon belül véletlenszerűen kerül kiválasztásra. Ez megakadályozza a “csorda effektust” (thundering herd), amikor sok kérés egyszerre jár le, és az összes ügyfél egyszerre fordul a forráshoz. A PEE különösen hasznos a CDN és a nagy terhelésű gyorsítótárak számára: az egységes 300 másodperces TTL helyett 240 és 360 másodperc közötti véletlenszerű értéket használnak, ami egyenletesen osztja el a terhelést a forráson.

TTL kódpéldák

Tekintsük át a gyorsítótár TTL-lel történő megvalósítását Kotlinban abszolút lejárat használatával. Minden rekord tárolja a létrehozás idejét, és olvasáskor ellenőrzi, hogy a TTL lejárt-e.

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) }
    }
}

Az Entry osztály tárolja az értéket és a létrehozási időt + TTL (abszolút lejárat). A get metódus minden hozzáférésnél ellenőrzi a lejáratot (lazy-cleanup) — a lejárt rekordok csak a hozzáférési kísérletkor törlődnek. A cleanup metódus időszakonként meghívható egy háttérszálból az összes elavult rekord kötegenkénti törléséhez. A ConcurrentHashMap szálbitonságot biztosít a teljes gyorsítótár blokkolása nélkül.

Példa: TTL API-válaszok gyorsítótárazásához iOS-en

iOS-ben a TTL-lel történő gyorsítótárazáshoz kényelmes az URLCache használata a memoryCapacity és diskCapacity beállításokkal. Az URLCache azonban nem támogatja az egyedi TTL-t a különböző kérésekhez. Tekintsük át az NSCache egyedi burkolóját TTL támogatással.

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
}

Ebben a megvalósításban az NSCache szálbiztos tárolóként szolgál. A CacheEntry Data-t és expirationDate-t tartalmaz. A get metódusnál ellenőrzésre kerül, hogy lejárt-e az idő; ha igen — a rekord törlődik és nil érték kerül visszaadásra. A TTL másodpercekben van megadva a TimeInterval segítségével, és URL-enként eltérő lehet: az API-válaszok tipikus értékei 120 másodperc a dinamikus tartalomhoz és 3600 a statikus adatokhoz.