TTL: bu nədir, keşin ömür müddəti və necə işləyir

TTL nədir?

TTL (Time To Live) — müddəti bitdikdən sonra məlumatların etibarsız sayıldığı vaxt markeri və ya intervaldır. Keşləmə kontekstində TTL qeydin mənbədən yenidən soruşulmazdan əvvəl keşdə nə qədər saxlanıla biləcəyini müəyyən edir. Şəbəkə protokollarında TTL paketin ömür müddətini məhdudlaşdıraraq sonsuz marşrutlaşdırmanın qarşısını alır.

TTL dəyəri həmişə vaxt vahidləri ilə ifadə olunur: millisaniyələr, saniyələr, dəqiqələr və ya saatlar. Müəyyən edilmiş vaxt bitdikdən sonra qeyd ya keşdən silinir, ya da stale (köhnəlmiş) kimi işarələnir. Köhnəlmiş qeydə növbəti sorğu zamanı sistem ya sonradan yeniləməklə köhnəlmiş məlumatları qaytara bilər (stale-while-revalidate), ya da təzə məlumat alınana qədər sorğunu bloklaya bilər.

TTL seçimi həmişə məlumatların aktual olması ilə performans arasında kompromisdir. Çox qısa TTL (1–5 saniyə) tətbiqi tez-tez şəbəkə sorğuları etməyə məcbur edərək keşləmənin faydasını azaldır. Çox uzun TTL (saatlar/günlər) istifadəçiyə köhnəlmiş məlumatların göstərilməsi riskini artırır. Optimal dəyər məlumat növündən asılıdır: valyuta məzənnələri — saniyələr, hava — dəqiqələr, API versiyası — saatlar.

TTL və keşin etibarsızlaşdırılması

TTL passiv etibarsızlaşdırmadır: məlumatlar müddət bitdikdən sonra avtomatik silinir. Alternativ — aktiv etibarsızlaşdırma, burada məlumat mənbəyi keşi dəyişikliklər barədə xəbərdar edir (məsələn, WebSocket mesajları və ya push bildirişləri vasitəsilə). Passiv etibarsızlaşdırma TTL vasitəsilə həyata keçirilməsi daha sadədir, lakin ani aktulluğu təmin etmir. Aktiv etibarsızlaşdırma daha mürəkkəbdir, lakin TTL-ə xas olan gecikmələr olmadan məlumatları aktual vəziyyətdə saxlamağa imkan verir.

TTL necə işləyir

TTL mexanizmi iki yolla həyata keçirilə bilər: mütləq bitmə (absolute expiration) və nisbi bitmə (relative expiration). Mütləq bitmədə qeyd etibarsız olacağı dəqiq vaxtı saxlayır. Nisbi bitmədə — qeydin yaradılma vaxtı və TTL interval kimi qeyd olunur, yoxlama isə creationTime + TTL > currentTime hesablanması ilə aparılır.

Keşə hər sorğuda sistem hər qeydin TTL-ni yoxlayır. Əgər TTL bitibsə, məlumatlar silinir və ya stale kimi işarələnir və sorğu mənbəyə yönləndirilir. TTL yoxlamasını optimallaşdırmaq üçün scheduled-cleanup (vaxtı keçmiş bütün qeydlərin dövri silinməsi) və ya lazy-cleanup (yalnız qeydə müraciət edildikdə silmə) istifadə edilə bilər. Lazy-cleanup yaddaş baxımından daha səmərəlidir, çünki bütün keşi skan etmək üçün fon axını tələb etmir.

Paylanmış sistemlərdə TTL avtomatik konfliktlərin həlli üçün də istifadə olunur. Məsələn, iki server eyni açar üçün fərqli dəyərlər yazıbsa, daha gec TTL-ə malik qeyd prioritet sayıla bilər. Amazon DynamoDB cədvəllərdə köhnəlmiş qeydlərin avtomatik silinməsi üçün TTL-dən istifadə edir — bu, əl ilə idarəetmə tələb etməyən daxili funksiyadır.

Köhnəlmiş oxu strategiyaları

TTL bitdikdən sonra performansı artırmaq üçün köhnəlmiş oxu strategiyaları tətbiq olunur. Stale-while-revalidate — dərhal müştəriyə köhnəlmiş məlumatları qaytar və eyni zamanda fon yeniləməsini işə sal. Stale-if-error — mənbə müvəqqəti əlçatan deyilsə, köhnəlmiş məlumatları qaytar. Cache-Aside (Lazy Loading) — keş boş olduqda məlumatları mənbədən yüklə, yeni TTL ilə keşdə saxla və yalnız sonra müştəriyə qaytar. Hər strategiya məlumat ardıcıllığı tələblərinə əsasən seçilir.

TTL məlumat keşləmədə

Mobil tətbiqlərdə TTL keş idarəetməsinin əsas mexanizmidir. TTL-nin tətbiq davranışını və istifadəçi təcrübəsini müəyyən etdiyi əsas ssenarilərə baxaq.

HTTP cavablarının keşlənməsi

HTTP protokolu Cache-Control başlıqları vasitəsilə daxili TTL mexanizmi təmin edir. max-age direktivi TTL-i saniyələrlə təyin edir: Cache-Control: public, max-age=3600 cavabın 1 saat keşlənə biləcəyi deməkdir. Əlavə direktivlər s-maxage (paylaşılan keşlər üçün, məsələn, CDN) və stale-while-revalidate daha incə idarəetmə təmin edir. TTL expires başlığı ilə üst-üstə düşərsə, daha müasir HTTP/1.1 standartı kimi max-age üstünlük təşkil edir.

Şəkillərin keşlənməsi

Şəkillər üçün TTL bir neçə günə çata bilər, çünki məzmun nadir hallarda dəyişir. Lakin mobil tətbiqlər tez-tez hibrid yanaşmadan istifadə edir: kiçik ölçülü şəkillər üçün qısa TTL (30 dəqiqə — kadrların aktulluğu) və tam ölçülü şəkillər üçün uzun TTL (7 gün). Şəkillər Cache-Control: immutable HTTP başlığı ilə TTL bitənə qədər ümumiyyətlə yenidən soruşulmamalıdır — bu, RFC 8246-da təklif edilən statik resurslar üçün optimallaşdırmadır. Belə şəkillər tətbiqin iştirakı olmadan OS səviyyəsində (URLCache, OkHttp Cache) keşlənir.

TTL şəbəkə protokollarında

Şəbəkələrdə TTL keşləmə üçün deyil, paketlərin ömür müddətini məhdudlaşdırmaq üçün istifadə olunur. Hər IP paketi TTL sahəsi (8 bit) ehtiva edir, hər marşrutlaşdırıcı onu 1 azaldır. TTL 0-a çatdıqda paket atılır və göndərənə ICMP Time Exceeded mesajı qaytarılır. Bu, şəbəkədə döngələr zamanı sonsuz marşrutlaşdırmanın qarşısını alır.

DNS-də TTL

DNS qeydləri rezolverin (məsələn, ISP DNS keşi) avtoritet serverə sorğu etmədən qeydi nə qədər saxlaya biləcəyini müəyyən edən TTL-ə malikdir. Tipik dəyərlər: tez-tez dəyişən qeydlər üçün 300 saniyə (5 dəqiqə), sabit domenlər üçün 86400 saniyə (24 saat). CDN xidmətləri nasazlıqlar zamanı trafikin sürətli yönləndirilməsi üçün tez-tez aşağı TTL (60–300 saniyə) təyin edir, statik domenlər isə 7 günə qədər TTL-ə malik ola bilər. Server miqrasiyası zamanı əvvəlcə TTL-i 60 saniyəyə endirmək tövsiyə olunur (miqrasiyadan 48 saat əvvəl), dəyişikliklərin sürətlə yayılması üçün.

Sessiyalarda və tokenlərdə TTL

Mobil tətbiqlərdə TTL sessiyaların və giriş tokenlərinin idarə edilməsi üçün istifadə olunur. JWT tokenləri (JSON Web Tokens) bitmə vaxtının mütləq Unix vaxtı olan exp sahəsini ehtiva edir. Bitdikdən sonra yeniləmə tokeni (refresh token) təkrar autentifikasiya olmadan yeni giriş tokeni əldə etmək üçün istifadə olunur. Giriş tokeninin TTL-i adətən 1–24 saat, yeniləmə tokeninin TTL-i isə 7–30 gün təşkil edir. Bu, təhlükəsizlik (qısa TTL sızma riskini azaldır) və istifadəçi təcrübəsi (uzun TTL təkrar girişlərin tezliyini azaldır) arasında balansdır.

TTL seçim strategiyaları

TTL seçimi məlumat növündən, aktulluq SLA-sından və təkrar sorğu dəyərindən asılı olan mühəndislik qərarıdır. Əsas strategiyaları nəzərdən keçirək.

Sabit TTL

Ən sadə yanaşma — bütün qeydlər eyni TTL-ə malikdir. Məsələn, bütün API cavablarını 5 dəqiqə keşləmək. Üstünlükləri: həyata keçirilmənin sadəliyi və proqnozlaşdırıla bilən davranış. Çatışmazlığı: müxtəlif məlumat növlərinin fərqli dəyişmə tezliyini nəzərə almır. Sabit TTL bütün qeydlərin eyni „təzəliyə“ malik olduğu homogen məlumatlar üçün əsaslandırılmışdır — məsələn, bir birjada kriptovalyuta məzənnəsi.

Adaptiv TTL

TTL məlumatların davranışından asılı olaraq dinamik dəyişir. Məsələn, qeyd serverdə nadir hallarda yenilənirsə, TTL artır; tez-tez yenilənirsə — azalır. Həyata keçirmə HTTP cavab başlıqlarından istifadə edə bilər: Age başlığı (cavabın keşdə nə qədər saniyə qaldığı) və Date başlığı qalan ömür müddətini hesablamağa imkan verir. Adaptiv TTL daha yaxşı hit-ratio təmin edir, lakin müştəri tərəfində əlavə məntiq tələb edir.

Ehtimali bitmə ilə TTL

Probabilistic Early Expiration (PEE) — TTL-in müəyyən diapazonda təsadüfi seçildiyi texnikadır. Bu, „sürü effektinin“ (thundering herd) qarşısını alır, bu zaman çoxlu sorğu eyni anda bitir və bütün müştərilər eyni anda mənbəyə müraciət edir. PEE xüsusilə CDN və yüksək yüklü keşlər üçün faydalıdır: vahid 300 saniyəlik TTL əvəzinə 240 ilə 360 saniyə arasında təsadüfi dəyər istifadə olunur ki, bu da mənbəyə yükü bərabər paylayır.

TTL kod nümunələri

Mütləq bitmədən istifadə edərək Kotlin dilində TTL ilə keşin həyata keçirilməsini nəzərdən keçirək. Hər qeyd yaradılma vaxtını saxlayır və oxuma zamanı TTL-in bitib-bitmədiyi yoxlanılır.

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 sinfi dəyəri və yaradılma vaxtı + TTL (mütləq bitmə) saxlayır. get metodu hər müraciətdə bitməni yoxlayır (lazy-cleanup) — vaxtı keçmiş qeydlər yalnız onlara giriş cəhdi zamanı silinir. cleanup metodu bütün köhnəlmiş qeydlərin toplu silinməsi üçün fon axınından dövri olaraq çağrıla bilər. ConcurrentHashMap bütün keşi bloklamadan thread təhlükəsizliyini təmin edir.

Nümunə: iOS-da API cavablarının keşlənməsi üçün TTL

iOS-də TTL ilə keşləmə üçün URLCache-dən memoryCapacity və diskCapacity parametrləri ilə istifadə etmək rahatdır. Lakin URLCache müxtəlif sorğular üçün fərdi TTL-i dəstəkləmir. TTL dəstəyi ilə NSCache-in xüsusi sarğısını nəzərdən keçirək.

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
}

Bu həyata keçirmədə NSCache thread təhlükəsiz yaddaş kimi istifadə olunur. CacheEntry Data və expirationDate ehtiva edir. get zamanı vaxtın bitib-bitmədiyi yoxlanılır; bitibsə — qeyd silinir və nil qaytarılır. TTL TimeInterval vasitəsilə saniyələrlə təyin edilir və hər URL üçün fərqli ola bilər: API cavabları üçün tipik dəyərlər dinamik məzmun üçün 120 saniyə və statik məlumatlar üçün 3600 saniyədir.