TTL: що це таке, час життя кешу та як працює

Що таке TTL?

TTL (Time To Live) — це мітка часу або інтервал, після якого дані вважаються недійсними. У контексті кешування TTL визначає, як довго запис може зберігатися в кеші, перш ніж його потрібно буде перезапитати з першоджерела. У мережевих протоколах TTL обмежує час життя пакета, запобігаючи нескінченній маршрутизації.

Значення TTL завжди виражається в одиницях часу: мілісекунди, секунди, хвилини або години. Після закінчення встановленого часу запис або видаляється з кешу, або позначається як застарілий. При наступному запиті до застарілого запису система може або повернути застарілі дані з наступним оновленням (stale-while-revalidate), або заблокувати запит до отримання свіжих даних.

Вибір TTL — це завжди компроміс між актуальністю даних та продуктивністю. Занадто короткий TTL (1–5 секунд) змушує додаток часто виконувати мережеві запити, зводячи нанівець вигоду від кешування. Занадто довгий TTL (години/дні) підвищує ризик показу користувачеві застарілої інформації. Оптимальне значення залежить від типу даних: курс валют — секунди, погода — хвилини, версія API — години.

TTL та інвалідація кешу

TTL — це пасивна інвалідація: дані видаляються автоматично після закінчення часу. Альтернатива — активна інвалідація, коли джерело даних повідомляє кеш про зміни (наприклад, через WebSocket-повідомлення або push-сповіщення). Пасивна інвалідація через TTL простіша в реалізації, але не гарантує миттєвої актуальності. Активна інвалідація складніша, але дозволяє підтримувати дані в актуальному стані без затримок, характерних для TTL.

Як працює TTL

Механізм TTL можна реалізувати двома способами: абсолютне закінчення (absolute expiration) та відносне закінчення (relative expiration). При абсолютному закінченні запис зберігає конкретний час, коли він стане недійсним. При відносному — фіксується час створення запису та TTL як інтервал, а перевірка виконується обчисленням creationTime + TTL > currentTime.

При кожному запиті до кешу система перевіряє TTL кожного запису. Якщо TTL минув, дані видаляються або позначаються як застарілі, і запит направляється до джерела. Для оптимізації перевірки TTL може використовуватися scheduled-очищення (періодичне видалення всіх прострочених записів) або lazy-очищення (видалення тільки при зверненні до запису). Lazy-очищення ефективніше по пам’яті, оскільки не потребує фонового потоку для сканування всього кешу.

У розподілених системах TTL також використовується для автоматичного вирішення конфліктів. Наприклад, якщо два сервери одночасно записали різні значення для одного ключа, запис із більш пізнім TTL може вважатися пріоритетним. Amazon DynamoDB використовує TTL для автоматичного видалення застарілих записів у таблицях — це вбудована функція, що не потребує ручного керування.

Стратегії stale-читання

Для підвищення продуктивності при закінченні TTL застосовуються стратегії stale-читання. Stale-while-revalidate — одразу повернути застарілі дані клієнту та одночасно запустити фонове оновлення. Stale-if-error — повернути stale-дані, якщо джерело тимчасово недоступне. Cache-Aside (Lazy Loading) — при промаху кешу завантажити дані з джерела, зберегти в кеші з новим TTL і лише потім повернути клієнту. Кожна стратегія вибирається виходячи з вимог до консистентності даних.

TTL у кешуванні даних

У мобільних додатках TTL — ключовий механізм керування кешем. Розглянемо основні сценарії, де TTL визначає поведінку додатка та користувацький досвід.

Кешування HTTP-відповідей

HTTP-протокол надає вбудований механізм TTL через заголовки Cache-Control. Директива max-age задає TTL у секундах: Cache-Control: public, max-age=3600 означає, що відповідь можна кешувати на 1 годину. Додаткові директиви s-maxage (для shared-кешів, наприклад, CDN) та stale-while-revalidate задають більш тонке керування. При збігу TTL з expires-заголовком пріоритет має max-age, як більш сучасний стандарт HTTP/1.1.

Кешування зображень

Для зображень TTL може досягати кількох днів, оскільки контент рідко змінюється. Однак мобільні додатки часто використовують гібридний підхід: короткий TTL для прев’ю (30 хвилин — актуальність кадрів) і довгий для повнорозмірних зображень (7 днів). Зображення з HTTP-заголовком Cache-Control: immutable взагалі не повинні перезапитуватися до закінчення TTL — це оптимізація для static-ресурсів, запропонована в RFC 8246. Такі зображення кешуються на рівні ОС (URLCache, OkHttp Cache) без участі додатка.

TTL у мережевих протоколах

У мережах TTL використовується не для кешування, а для обмеження часу життя пакетів. Кожен IP-пакет містить поле TTL (8 біт), яке зменшується на 1 кожним маршрутизатором. Коли TTL досягає 0, пакет відкидається, а відправнику повертається ICMP-повідомлення Time Exceeded. Це запобігає нескінченній маршрутизації при петлях у мережі.

TTL у DNS

DNS-записи мають TTL, який визначає, як довго резолвер (наприклад, ISP DNS-кеш) може зберігати запис без запиту до авторитетного сервера. Типові значення: 300 секунд (5 хвилин) для записів із частими змінами, 86400 секунд (24 години) для стабільних доменів. CDN-сервіси часто встановлюють низький TTL (60–300 секунд) для швидкого перенаправлення трафіку при збоях, тоді як статичні домени можуть мати TTL до 7 днів. При міграції сервера рекомендується спочатку знизити TTL до 60 секунд (за 48 годин до міграції), щоб зміни поширилися швидко.

TTL у сесіях та токенах

У мобільних додатках TTL використовується для керування сесіями та токенами доступу. JWT-токени (JSON Web Tokens) містять поле exp (expiration time), яке є абсолютним Unix-часом закінчення. Після закінчення refresh-токен використовується для отримання нового access-токена без повторної аутентифікації. TTL access-токена зазвичай становить 1–24 години, refresh-токена — 7–30 днів. Це баланс між безпекою (короткий TTL знижує ризик витоку) та UX (довгий TTL зменшує частоту повторних логінів).

Стратегії вибору TTL

Вибір TTL — інженерне рішення, що залежить від типу даних, SLA щодо актуальності та вартості повторного запиту. Розглянемо основні стратегії.

Фіксований TTL

Найпростіший підхід — всі записи мають однаковий TTL. Наприклад, кешувати всі API-відповіді на 5 хвилин. Перевага: простота реалізації та передбачувана поведінка. Недолік: не враховує різну частоту змін різних типів даних. Фіксований TTL виправданий для однорідних даних, де всі записи мають однакову «свіжість» — наприклад, курс криптовалют на одній біржі.

Адаптивний TTL

TTL динамічно змінюється залежно від поведінки даних. Наприклад, якщо запис рідко оновлюється на сервері, TTL збільшується; якщо оновлюється часто — зменшується. Реалізація може використовувати заголовки HTTP-відповідей: заголовок Age (скільки секунд відповідь уже провела в кеші) та заголовок Date дозволяють розрахувати час, що залишився. Адаптивний TTL дає кращий hit-ratio, але потребує додаткової логіки на клієнті.

TTL з імовірнісним закінченням

Probabilistic Early Expiration (PEE) — техніка, при якій TTL вибирається випадковим чином у заданому діапазоні. Це запобігає «ефекту стада» (thundering herd), коли безліч запитів одночасно закінчуються і всі клієнти одночасно звертаються до джерела. PEE особливо корисна для CDN та кешів з високим навантаженням: замість єдиного TTL у 300 секунд використовується випадкове значення від 240 до 360 секунд, що розподіляє навантаження на джерело рівномірно.

Приклади коду TTL

Розглянемо реалізацію кешу з TTL на Kotlin з використанням абсолютного закінчення. Кожен запис зберігає час створення, і при читанні перевіряється, чи не минув TTL.

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

Клас Entry зберігає значення та час створення + TTL (абсолютне закінчення). Метод get перевіряє закінчення при кожному зверненні (lazy-очищення) — прострочені записи видаляються тільки при спробі доступу до них. Метод cleanup можна викликати періодично з фонового потоку для пакетного видалення всіх застарілих записів. ConcurrentHashMap забезпечує потокобезпеку без блокування всього кешу.

Приклад: TTL для кешування API-відповідей на iOS

В iOS для кешування з TTL зручно використовувати URLCache з налаштуванням memoryCapacity та diskCapacity. Однак URLCache не підтримує індивідуальний TTL для різних запитів. Розглянемо кастомну обгортку NSCache з підтримкою 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
}

У цій реалізації NSCache використовується як потокобезпечне сховище. CacheEntry містить Data та expirationDate. При get перевіряється, чи не минув час; якщо минув — запис видаляється та повертається nil. TTL задається в секундах через TimeInterval і може бути різним для кожного URL: типові значення для API-відповідей — 120 секунд для динамічного контенту та 3600 для статичних даних.