TTL: co to jest, czas życia pamięci podręcznej i jak działa

Co to jest TTL?

TTL (Time To Live) — to znacznik czasu lub interwał, po którym dane są uznawane za nieaktualne. W kontekście buforowania TTL określa, jak długo rekord może być przechowywany w pamięci podręcznej, zanim będzie trzeba go ponownie pobrać ze źródła. W protokołach sieciowych TTL ogranicza czas życia pakietu, zapobiegając nieskończonemu routowaniu.

Wartość TTL jest zawsze wyrażana w jednostkach czasu: milisekundy, sekundy, minuty lub godziny. Po upływie ustawionego czasu rekord jest albo usuwany z pamięci podręcznej, albo oznaczany jako stale (nieaktualny). Przy następnym żądaniu do nieaktualnego rekordu system może zwrócić nieaktualne dane z późniejszym odświeżeniem (stale-while-revalidate) lub zablokować żądanie do czasu otrzymania świeżych danych.

Wybór TTL to zawsze kompromis między aktualnością danych a wydajnością. Zbyt krótki TTL (1–5 sekund) zmusza aplikację do częstego wykonywania zapytań sieciowych, niwelując korzyści z buforowania. Zbyt długi TTL (godziny/dni) zwiększa ryzyko wyświetlenia użytkownikowi nieaktualnych informacji. Optymalna wartość zależy od typu danych: kursy walut — sekundy, pogoda — minuty, wersja API — godziny.

TTL i unieważnianie pamięci podręcznej

TTL to pasywne unieważnianie: dane są automatycznie usuwane po upływie czasu. Alternatywą jest aktywne unieważnianie, gdy źródło danych powiadamia pamięć podręczną o zmianach (np. poprzez WebSocket lub powiadomienia push). Pasywne unieważnianie przez TTL jest prostsze w implementacji, ale nie gwarantuje natychmiastowej aktualności. Aktywne unieważnianie jest bardziej złożone, ale pozwala utrzymywać dane w aktualnym stanie bez opóźnień charakterystycznych dla TTL.

Jak działa TTL

Mechanizm TTL można zaimplementować na dwa sposoby: wygaśnięcie absolutne (absolute expiration) i wygaśnięcie względne (relative expiration). Przy wygaśnięciu absolutnym rekord przechowuje konkretny czas, po którym stanie się nieaktualny. Przy wygaśnięciu względnym — zapisywany jest czas utworzenia rekordu i TTL jako interwał, a sprawdzenie wykonuje się poprzez obliczenie creationTime + TTL > currentTime.

Przy każdym żądaniu do pamięci podręcznej system sprawdza TTL każdego rekordu. Jeśli TTL wygasł, dane są usuwane lub oznaczane jako stale, a żądanie kierowane jest do źródła. Do optymalizacji sprawdzania TTL można użyć scheduled-cleanup (okresowe usuwanie wszystkich wygasłych rekordów) lub lazy-cleanup (usuwanie tylko przy dostępie do rekordu). Lazy-cleanup jest bardziej efektywny pamięciowo, ponieważ nie wymaga wątku tła do skanowania całej pamięci podręcznej.

W systemach rozproszonych TTL jest również używany do automatycznego rozwiązywania konfliktów. Na przykład, jeśli dwa serwery jednocześnie zapisały różne wartości dla tego samego klucza, rekord z późniejszym TTL może być uznany za priorytetowy. Amazon DynamoDB używa TTL do automatycznego usuwania nieaktualnych rekordów w tabelach — to wbudowana funkcja, która nie wymaga ręcznego zarządzania.

Strategie odczytu nieaktualnych danych

Aby zwiększyć wydajność po wygaśnięciu TTL, stosuje się strategie odczytu nieaktualnych danych. Stale-while-revalidate — natychmiast zwróć nieaktualne dane klientowi i jednocześnie uruchom aktualizację w tle. Stale-if-error — zwróć nieaktualne dane, jeśli źródło jest tymczasowo niedostępne. Cache-Aside (Lazy Loading) — w przypadku braku w pamięci podręcznej załaduj dane ze źródła, zapisz w pamięci podręcznej z nowym TTL i dopiero potem zwróć klientowi. Każda strategia jest wybierana na podstawie wymagań dotyczących spójności danych.

TTL w buforowaniu danych

W aplikacjach mobilnych TTL to kluczowy mechanizm zarządzania pamięcią podręczną. Rozważmy główne scenariusze, w których TTL określa zachowanie aplikacji i doświadczenie użytkownika.

Buforowanie odpowiedzi HTTP

Protokół HTTP udostępnia wbudowany mechanizm TTL poprzez nagłówki Cache-Control. Dyrektywa max-age określa TTL w sekundach: Cache-Control: public, max-age=3600 oznacza, że odpowiedź może być buforowana przez 1 godzinę. Dodatkowe dyrektywy s-maxage (dla współdzielonych pamięci podręcznych, np. CDN) i stale-while-revalidate zapewniają bardziej precyzyjne zarządzanie. W przypadku zgodności TTL z nagłówkiem expires pierwszeństwo ma max-age jako bardziej nowoczesny standard HTTP/1.1.

Buforowanie obrazów

Dla obrazów TTL może sięgać kilku dni, ponieważ treść rzadko się zmienia. Jednak aplikacje mobilne często stosują podejście hybrydowe: krótki TTL dla miniatur (30 minut — aktualność kadrów) i długi dla obrazów w pełnym rozmiarze (7 dni). Obrazy z nagłówkiem HTTP Cache-Control: immutable w ogóle nie powinny być ponownie żądane przed wygaśnięciem TTL — to optymalizacja dla zasobów statycznych zaproponowana w RFC 8246. Takie obrazy są buforowane na poziomie systemu operacyjnego (URLCache, OkHttp Cache) bez udziału aplikacji.

TTL w protokołach sieciowych

W sieciach TTL jest używany nie do buforowania, ale do ograniczania czasu życia pakietów. Każdy pakiet IP zawiera pole TTL (8 bitów), które jest zmniejszane o 1 przez każdy router. Gdy TTL osiągnie 0, pakiet jest odrzucany, a nadawca otrzymuje komunikat ICMP Time Exceeded. Zapobiega to nieskończonemu routowaniu przy pętlach w sieci.

TTL w DNS

Rekordy DNS mają TTL określający, jak długo resolver (np. pamięć podręczna DNS dostawcy internetu) może przechowywać rekord bez zapytania do serwera autorytatywnego. Typowe wartości: 300 sekund (5 minut) dla rekordów z częstymi zmianami, 86400 sekund (24 godziny) dla stabilnych domen. Usługi CDN często ustawiają niski TTL (60–300 sekund) dla szybkiego przekierowania ruchu w przypadku awarii, podczas gdy statyczne domeny mogą mieć TTL do 7 dni. Podczas migracji serwera zaleca się najpierw obniżyć TTL do 60 sekund (48 godzin przed migracją), aby zmiany rozprzestrzeniły się szybko.

TTL w sesjach i tokenach

W aplikacjach mobilnych TTL jest używany do zarządzania sesjami i tokenami dostępu. Tokeny JWT (JSON Web Tokens) zawierają pole exp (czas wygaśnięcia), które jest absolutnym czasem Unix wygaśnięcia. Po wygaśnięciu token odświeżania (refresh token) jest używany do uzyskania nowego tokena dostępu bez ponownego uwierzytelniania. TTL tokena dostępu wynosi zwykle 1–24 godziny, tokena odświeżania — 7–30 dni. To równowaga między bezpieczeństwem (krótki TTL zmniejsza ryzyko wycieku) a wygodą użytkownika (długi TTL zmniejsza częstotliwość ponownych logowań).

Strategie wyboru TTL

Wybór TTL to decyzja inżynieryjna zależna od typu danych, SLA dotyczącego aktualności i kosztu ponownego żądania. Rozważmy główne strategie.

Stały TTL

Najprostsze podejście — wszystkie rekordy mają ten sam TTL. Na przykład buforowanie wszystkich odpowiedzi API przez 5 minut. Zalety: prostota implementacji i przewidywalne zachowanie. Wada: nie uwzględnia różnej częstotliwości zmian różnych typów danych. Stały TTL jest uzasadniony dla jednorodnych danych, gdzie wszystkie rekordy mają tę samą „świeżość” — na przykład kurs kryptowalut na jednej giełdzie.

Adaptacyjny TTL

TTL zmienia się dynamicznie w zależności od zachowania danych. Na przykład, jeśli rekord rzadko jest aktualizowany na serwerze, TTL wzrasta; jeśli aktualizowany często — maleje. Implementacja może wykorzystywać nagłówki odpowiedzi HTTP: nagłówek Age (ile sekund odpowiedź już spędziła w pamięci podręcznej) i nagłówek Date pozwalają obliczyć pozostały czas życia. Adaptacyjny TTL zapewnia lepszy hit-ratio, ale wymaga dodatkowej logiki po stronie klienta.

TTL z probabilistycznym wygaśnięciem

Probabilistic Early Expiration (PEE) — technika, w której TTL jest wybierany losowo w zadanym zakresie. Zapobiega to „efektowi stada” (thundering herd), gdy wiele żądań wygasa jednocześnie i wszyscy klienci jednocześnie zwracają się do źródła. PEE jest szczególnie przydatna dla CDN i pamięci podręcznych o dużym obciążeniu: zamiast jednolitego TTL 300 sekund stosuje się losową wartość od 240 do 360 sekund, co równomiernie rozkłada obciążenie źródła.

Przykłady kodu TTL

Rozważmy implementację pamięci podręcznej z TTL w Kotlin z użyciem wygaśnięcia absolutnego. Każdy rekord przechowuje czas utworzenia, a przy odczycie sprawdzane jest, czy TTL nie wygasł.

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

Klasa Entry przechowuje wartość oraz czas utworzenia + TTL (wygaśnięcie absolutne). Metoda get sprawdza wygaśnięcie przy każdym dostępie (lazy-cleanup) — przedawnione rekordy są usuwane tylko przy próbie dostępu do nich. Metodę cleanup można wywoływać okresowo z wątku tła do wsadowego usuwania wszystkich nieaktualnych rekordów. ConcurrentHashMap zapewnia bezpieczeństwo wątków bez blokowania całej pamięci podręcznej.

Przykład: TTL dla buforowania odpowiedzi API na iOS

W iOS do buforowania z TTL wygodnie jest użyć URLCache z konfiguracją memoryCapacity i diskCapacity. Jednak URLCache nie obsługuje indywidualnego TTL dla różnych żądań. Rozważmy niestandardową otoczkę NSCache z obsługą TTL.

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
}

W tej implementacji NSCache jest używany jako bezpieczne dla wątków magazyn. CacheEntry zawiera Data i expirationDate. Przy get sprawdzane jest, czy czas nie wygasł; jeśli wygasł — rekord jest usuwany i zwracane jest nil. TTL jest ustawiany w sekundach przez TimeInterval i może być różny dla każdego URL: typowe wartości dla odpowiedzi API to 120 sekund dla dynamicznej treści i 3600 dla danych statycznych.