TTL: nedir, önbellek yaşam süresi ve nasıl çalışır

TTL Nedir?

TTL (Time To Live), verilerin geçersiz kabul edildiği bir zaman damgası veya aralıktır. Önbellekleme bağlamında TTL, bir kaydın kaynaktan yeniden alınması gerekmeden önce önbellekte ne kadar süre saklanabileceğini belirler. Ağ protokollerinde TTL, bir paketin ömrünü sınırlayarak sonsuz yönlendirmeyi önler.

TTL değeri her zaman zaman birimleriyle ifade edilir: milisaniye, saniye, dakika veya saat. Ayarlanan süre dolduğunda, kayıt önbellekten silinir veya eski olarak işaretlenir. Eski bir kayda yapılan sonraki istekte, sistem daha sonraki bir güncellemeyle (stale-while-revalidate) birlikte eski verileri döndürebilir veya taze veri elde edilene kadar isteği engelleyebilir.

TTL seçmek her zaman veri tazeliği ve performans arasında bir dengedir. Çok kısa bir TTL (1–5 saniye), uygulamayı sık ağ istekleri yapmaya zorlayarak önbelleklemenin avantajını ortadan kaldırır. Çok uzun bir TTL (saatler/günler), kullanıcıya eski bilgileri gösterme riskini artırır. Optimum değer veri türüne bağlıdır: döviz kurları — saniye, hava durumu — dakika, API sürümü — saat.

TTL ve Önbellek Geçersizleştirme

TTL pasif geçersizleştirmedir: veriler belirli bir süre sonra otomatik olarak kaldırılır. Alternatif, veri kaynağının değişiklikleri önbelleğe bildirdiği aktif geçersizleştirmedir (örneğin WebSocket mesajları veya push bildirimleri aracılığıyla). TTL aracılığıyla pasif geçersizleştirme uygulaması daha basittir ancak anında tazelik garantisi vermez. Aktif geçersizleştirme daha karmaşıktır ancak verileri TTL'nin doğasındaki gecikmeler olmadan güncel tutmaya olanak tanır.

TTL Nasıl Çalışır

TTL mekanizması iki şekilde uygulanabilir: mutlak süre sonu (absolute expiration) ve göreceli süre sonu (relative expiration). Mutlak süre sonunda, kayıt geçersiz olacağı belirli zamanı saklar. Göreceli süre sonunda, kaydın oluşturulma zamanı ve TTL bir aralık olarak kaydedilir ve kontrol creationTime + TTL > currentTime hesaplanarak yapılır.

Önbelleğe yapılan her istekte, sistem her kaydın TTL'sini kontrol eder. TTL süresi dolmuşsa, veriler silinir veya eski olarak işaretlenir ve istek kaynağa yönlendirilir. TTL kontrolünü optimize etmek için, zamanlanmış temizleme (süresi dolan tüm kayıtların periyodik olarak silinmesi) veya tembel temizleme (yalnızca kayda erişildiğinde silme) kullanılabilir. Tembel temizleme, tüm önbelleği taramak için bir arka plan iş parçacığı gerektirmediğinden bellek açısından daha verimlidir.

Dağıtık sistemlerde, TTL otomatik çakışma çözümü için de kullanılır. Örneğin, iki sunucu aynı anahtar için aynı anda farklı değerler yazarsa, daha sonraki TTL'ye sahip kayıt öncelikli kabul edilebilir. Amazon DynamoDB, tablolardaki eski kayıtları otomatik olarak silmek için TTL kullanır — bu, manuel yönetim gerektirmeyen yerleşik bir özelliktir.

Eski Veri Okuma Stratejileri

TTL süresi dolduğunda performansı artırmak için eski veri okuma stratejileri kullanılır. Stale-while-revalidate — eski verileri hemen istemciye döndür ve aynı anda bir arka plan güncellemesi başlat. Stale-if-error — kaynak geçici olarak kullanılamıyorsa eski verileri döndür. Cache-Aside (Lazy Loading) — önbellek vurusuzluğunda, verileri kaynaktan yükle, yeni bir TTL ile önbellekte sakla ve ancak ondan sonra istemciye döndür. Her strateji, veri tutarlılığı gereksinimlerine göre seçilir.

Veri Önbelleklemede TTL

Mobil uygulamalarda TTL, önbellek yönetimi için anahtar bir mekanizmadır. TTL'nin uygulama davranışını ve kullanıcı deneyimini belirlediği ana senaryolara bakalım.

HTTP Yanıtlarını Önbelleğe Alma

HTTP protokolü, Cache-Control başlıkları aracılığıyla yerleşik bir TTL mekanizması sağlar. max-age yönergesi TTL'yi saniye cinsinden ayarlar: Cache-Control: public, max-age=3600, yanıtın 1 saat önbellekte tutulabileceği anlamına gelir. Ek yönergeler s-maxage (paylaşılan önbellekler için, örn. CDN) ve stale-while-revalidate daha ince ayarlı kontrol sağlar. TTL, expires başlığıyla çakıştığında, daha modern HTTP/1.1 standardı olarak max-age öncelik alır.

Görselleri Önbelleğe Alma

Görseller için, içerik nadiren değiştiğinden TTL birkaç günü bulabilir. Ancak mobil uygulamalar genellikle hibrit bir yaklaşım kullanır: önizlemeler için kısa TTL (30 dakika — kare tazeliği) ve tam boyutlu görseller için uzun TTL (7 gün). HTTP başlığı Cache-Control: immutable olan görseller, TTL süresi dolana kadar yeniden istenmemelidir — bu, RFC 8246'da önerilen statik kaynaklar için bir optimizasyondur. Bu tür görseller, uygulama katılımı olmadan işletim sistemi düzeyinde (URLCache, OkHttp Cache) önbelleğe alınır.

Ağ Protokollerinde TTL

Ağlarda TTL, önbellekleme için değil, paketlerin ömrünü sınırlamak için kullanılır. Her IP paketi, her yönlendirici tarafından 1 azaltılan bir TTL alanı (8 bit) içerir. TTL 0'a ulaştığında, paket atılır ve gönderen bir ICMP Time Exceeded mesajı alır. Bu, ağ döngüleri sırasında sonsuz yönlendirmeyi önler.

DNS'te TTL

DNS kayıtları, bir çözümleyicinin (örneğin ISP DNS önbelleği) yetkili sunucuya sormadan kaydı ne kadar süre saklayabileceğini belirleyen bir TTL'ye sahiptir. Tipik değerler: sık değişen kayıtlar için 300 saniye (5 dakika), kararlı alan adları için 86400 saniye (24 saat). CDN hizmetleri genellikle arızalar sırasında hızlı trafik yönlendirmesi için düşük TTL (60–300 saniye) ayarlarken, statik alan adları 7 güne kadar TTL'ye sahip olabilir. Bir sunucu taşınırken, değişikliklerin hızla yayılması için önce TTL'nin 60 saniyeye düşürülmesi önerilir (taşınmadan 48 saat önce).

Oturumlarda ve Tokenlarda TTL

Mobil uygulamalarda TTL, oturumları ve erişim tokenlarını yönetmek için kullanılır. JWT tokenları (JSON Web Tokens), mutlak Unix süre sonu zamanı olan bir exp (süre sonu) alanı içerir. Süre sonunda, yeniden kimlik doğrulama olmadan yeni bir erişim tokenı almak için bir yenileme tokenı kullanılır. Erişim tokenı TTL'si genellikle 1–24 saat, yenileme tokenı TTL'si 7–30 gündür. Bu, güvenlik (kısa TTL sızıntı riskini azaltır) ve UX (uzun TTL yeniden oturum açma sıklığını azaltır) arasında bir dengedir.

TTL Seçim Stratejileri

TTL seçimi, veri türüne, tazelik SLA'sına ve yeniden istek maliyetine bağlı bir mühendislik kararıdır. Ana stratejileri inceleyelim.

Sabit TTL

En basit yaklaşım — tüm kayıtlar aynı TTL'ye sahiptir. Örneğin, tüm API yanıtlarını 5 dakika önbelleğe alın. Avantaj: uygulama basitliği ve öngörülebilir davranış. Dezavantaj: farklı veri türlerinin farklı değişim sıklığını hesaba katmaz. Sabit TTL, tüm kayıtların aynı “tazeliğe” sahip olduğu homojen veriler için uygundur — örneğin, tek bir borsadaki kripto para kurları.

Uyarlanabilir TTL

TTL, veri davranışına göre dinamik olarak değişir. Örneğin, bir kayıt sunucuda nadiren güncelleniyorsa TTL artar; sık güncelleniyorsa azalır. Uygulama, HTTP yanıt başlıklarını kullanabilir: Age başlığı (yanıtın önbellekte kaç saniyedir olduğu) ve Date başlığı, kalan ömrün hesaplanmasına olanak tanır. Uyarlanabilir TTL daha iyi bir isabet oranı sağlar ancak istemcide ek mantık gerektirir.

Olasılıklı TTL Süresinin Dolması

Probabilistic Early Expiration (PEE) — TTL'nin belirli bir aralıkta rastgele seçildiği bir tekniktir. Bu, birçok isteğin aynı anda süresinin dolduğu ve tüm istemcilerin aynı anda kaynağa eriştiği “thundering herd” etkisini önler. PEE özellikle CDN'ler ve yüksek yüklü önbellekler için kullanışlıdır: 300 saniyelik tek bir TTL yerine, kaynak üzerindeki yükü eşit olarak dağıtan 240 ila 360 saniye arasında rastgele bir değer kullanılır.

TTL Kod Örnekleri

Mutlak süre sonu kullanarak Kotlin'de TTL'li bir önbellek uygulamasına bakalım. Her kayıt oluşturulma zamanını saklar ve okuma sırasında TTL'nin dolup dolmadığı kontrol edilir.

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 sınıfı, değeri ve oluşturma zamanı + TTL'yi (mutlak süre sonu) saklar. get metodu, her erişimde süre sonunu kontrol eder (tembel temizleme) — süresi dolan kayıtlar yalnızca onlara erişmeye çalışıldığında silinir. cleanup metodu, tüm eski kayıtları toplu olarak silmek için bir arka plan iş parçacığından periyodik olarak çağrılabilir. ConcurrentHashMap, tüm önbelleği kilitlemeden iş parçacığı güvenliği sağlar.

Örnek: iOS'ta API Yanıtlarını Önbelleğe Almak İçin TTL

iOS'ta, TTL ile önbellekleme için memoryCapacity ve diskCapacity ayarlarıyla URLCache kullanmak uygundur. Ancak URLCache, farklı istekler için bireysel TTL'yi desteklemez. TTL desteği olan özel bir NSCache sarmalayıcısını ele alalım.

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 uygulamada NSCache, iş parçacığı güvenli depolama olarak kullanılır. CacheEntry, Data ve expirationDate içerir. get çağrıldığında, zamanın dolup dolmadığını kontrol eder; dolduysa kayıt silinir ve nil döndürülür. TTL, TimeInterval aracılığıyla saniye cinsinden ayarlanır ve her URL için farklı olabilir: API yanıtları için tipik değerler dinamik içerik için 120 saniye ve statik veriler için 3600'dür.