TTL: ano ito, buhay ng cache at kung paano ito gumagana

Ano ang TTL?

TTL (Time To Live) — ay isang time marker o interval pagkatapos nito ang data ay itinuturing na hindi wasto. Sa konteksto ng caching, tinutukoy ng TTL kung gaano katagal maiimbak ang isang record sa cache bago ito kailangang hilingin muli mula sa orihinal na pinagmulan. Sa mga network protocol, nililimitahan ng TTL ang buhay ng isang packet, na pumipigil sa walang katapusang routing.

Ang halaga ng TTL ay palaging ipinapahayag sa mga yunit ng oras: millisecond, segundo, minuto o oras. Pagkatapos ng itinakdang oras, ang record ay tatanggalin mula sa cache o mamarkahan bilang stale (luma). Sa susunod na kahilingan sa isang lumang record, ang system ay maaaring magbalik ng lumang data na may kasunod na pag-update (stale-while-revalidate) o harangan ang kahilingan hanggang sa matanggap ang sariwang data.

Ang pagpili ng TTL ay palaging isang kompromiso sa pagitan ng pagiging napapanahon ng data at performance. Ang masyadong maikling TTL (1-5 segundo) ay pinipilit ang application na madalas magsagawa ng mga network request, na nag-aalis ng benepisyo ng caching. Ang masyadong mahabang TTL (oras/araw) ay nagpapataas ng panganib ng pagpapakita ng lumang impormasyon sa user. Ang optimal na halaga ay depende sa uri ng data: halaga ng palitan — segundo, panahon — minuto, bersyon ng API — oras.

TTL at invalidation ng cache

Ang TTL ay passive invalidation: ang data ay awtomatikong tinatanggal pagkatapos ng itinakdang oras. Ang alternatibo ay active invalidation, kung saan ang pinagmulan ng data ay nag-aabiso sa cache tungkol sa mga pagbabago (halimbawa, sa pamamagitan ng WebSocket na mga mensahe o push notification). Ang passive invalidation sa pamamagitan ng TTL ay mas simple sa implementasyon, ngunit hindi ginagarantiya ang agarang pagiging napapanahon. Ang active invalidation ay mas kumplikado, ngunit pinapayagan ang data na manatiling napapanahon nang walang mga pagkaantala na katangian ng TTL.

Paano gumagana ang TTL

Ang mekanismo ng TTL ay maaaring ipatupad sa dalawang paraan: absolute expiration at relative expiration. Sa absolute expiration, ang record ay nag-iimbak ng tiyak na oras kung kailan ito magiging hindi wasto. Sa relative expiration — ang oras ng paggawa ng record at TTL bilang interval ay naitala, at ang pagsusuri ay ginagawa sa pamamagitan ng pagkalkula ng creationTime + TTL > currentTime.

Sa bawat kahilingan sa cache, sinusuri ng system ang TTL ng bawat record. Kung ang TTL ay nag-expire na, ang data ay tatanggalin o mamarkahan bilang stale, at ang kahilingan ay ididirekta sa pinagmulan. Para ma-optimize ang pagsusuri ng TTL, maaaring gamitin ang scheduled-cleanup (pana-panahong pagtanggal ng lahat ng expired na record) o lazy-cleanup (pagtanggal lamang kapag ina-access ang record). Ang lazy-cleanup ay mas mahusay sa memory dahil hindi ito nangangailangan ng background thread para i-scan ang buong cache.

Sa mga distributed system, ang TTL ay ginagamit din para sa awtomatikong paglutas ng conflict. Halimbawa, kung dalawang server ang sabay na sumulat ng magkaibang halaga para sa parehong key, ang record na may mas huling TTL ay maaaring ituring na prayoridad. Ang Amazon DynamoDB ay gumagamit ng TTL para sa awtomatikong pagtanggal ng mga lumang record sa mga table — ito ay isang built-in na function na hindi nangangailangan ng manual na pamamahala.

Mga estratehiya sa pagbabasa ng lumang data

Para mapataas ang performance pagkatapos mag-expire ang TTL, inilalapat ang mga estratehiya sa pagbabasa ng lumang data. Stale-while-revalidate — agad na ibalik ang lumang data sa client at sabay na magpatakbo ng background update. Stale-if-error — ibalik ang lumang data kung ang pinagmulan ay pansamantalang hindi available. Cache-Aside (Lazy Loading) — kapag miss ang cache, i-load ang data mula sa pinagmulan, i-save sa cache na may bagong TTL at saka ibalik sa client. Ang bawat estratehiya ay pinipili batay sa mga kinakailangan sa consistency ng data.

TTL sa pag-cache ng data

Sa mga mobile application, ang TTL ay ang pangunahing mekanismo ng pamamahala ng cache. Tingnan natin ang mga pangunahing scenario kung saan tinutukoy ng TTL ang pag-uugali ng application at karanasan ng user.

Pag-cache ng mga tugon ng HTTP

Ang HTTP protocol ay nagbibigay ng built-in na mekanismo ng TTL sa pamamagitan ng mga header na Cache-Control. Ang direktiba na max-age ay nagtatakda ng TTL sa mga segundo: Cache-Control: public, max-age=3600 ay nangangahulugan na ang tugon ay maaaring i-cache ng 1 oras. Ang mga karagdagang direktiba na s-maxage (para sa shared cache, hal. CDN) at stale-while-revalidate ay nagbibigay ng mas pinong kontrol. Kung ang TTL ay tumugma sa header na expires, ang max-age ay may prayoridad bilang mas modernong HTTP/1.1 standard.

Pag-cache ng mga larawan

Para sa mga larawan, ang TTL ay maaaring umabot ng ilang araw, dahil ang nilalaman ay bihirang magbago. Gayunpaman, ang mga mobile application ay madalas na gumagamit ng hybrid approach: maikling TTL para sa mga preview (30 minuto — pagiging napapanahon ng frame) at mahabang TTL para sa full-size na mga larawan (7 araw). Ang mga larawan na may HTTP header na Cache-Control: immutable ay hindi dapat hilingin muli hanggang sa mag-expire ang TTL — ito ay isang optimization para sa static na resources na iminungkahi sa RFC 8246. Ang mga naturang larawan ay naka-cache sa antas ng operating system (URLCache, OkHttp Cache) nang walang partisipasyon ng application.

TTL sa mga network protocol

Sa mga network, ang TTL ay ginagamit hindi para sa caching, kundi para sa paglilimita sa buhay ng mga packet. Ang bawat IP packet ay naglalaman ng TTL field (8 bits) na binabawasan ng 1 ng bawat router. Kapag ang TTL ay umabot sa 0, ang packet ay itatapon, at ang ICMP Time Exceeded na mensahe ay ibabalik sa nagpadala. Ito ay pumipigil sa walang katapusang routing sa mga loop sa network.

TTL sa DNS

Ang mga record ng DNS ay may TTL na tumutukoy kung gaano katagal maaaring iimbak ng resolver (halimbawa, DNS cache ng ISP) ang record nang hindi nagtatanong sa authoritative server. Karaniwang halaga: 300 segundo (5 minuto) para sa mga record na may madalas na pagbabago, 86400 segundo (24 oras) para sa stable na mga domain. Ang mga serbisyo ng CDN ay madalas na nagtatakda ng mababang TTL (60-300 segundo) para sa mabilis na pag-redirect ng trapiko sa panahon ng failure, habang ang static na mga domain ay maaaring magkaroon ng TTL hanggang 7 araw. Sa pag-migrate ng server, inirerekomenda na babaan muna ang TTL sa 60 segundo (48 oras bago ang migration) upang mabilis na kumalat ang mga pagbabago.

TTL sa mga session at token

Sa mga mobile application, ang TTL ay ginagamit para sa pamamahala ng mga session at access token. Ang mga JWT token (JSON Web Tokens) ay naglalaman ng exp field (expiration time) na absolute Unix time ng expiration. Pagkatapos mag-expire, ang refresh token ay ginagamit para makakuha ng bagong access token nang walang re-authentication. Ang TTL ng access token ay karaniwang 1-24 oras, ang TTL ng refresh token ay 7-30 araw. Ito ay balanse sa pagitan ng seguridad (maikling TTL ay nagbabawas ng panganib ng leakage) at karanasan ng user (mahabang TTL ay nagbabawas ng dalas ng muling pag-login).

Mga estratehiya sa pagpili ng TTL

Ang pagpili ng TTL ay isang engineering decision na nakadepende sa uri ng data, SLA ng pagiging napapanahon at gastos ng muling kahilingan. Tingnan natin ang mga pangunahing estratehiya.

Fixed TTL

Ang pinakasimpleng approach — lahat ng record ay may parehong TTL. Halimbawa, i-cache ang lahat ng tugon ng API sa loob ng 5 minuto. Bentahe: simple ang implementasyon at predictable ang pag-uugali. Disbentahe: hindi isinasaalang-alang ang iba't ibang dalas ng pagbabago ng iba't ibang uri ng data. Ang fixed TTL ay makatwiran para sa homogeneous na data kung saan ang lahat ng record ay may parehong ‛kasariwaan“ — halimbawa, ang halaga ng cryptocurrency sa isang exchange.

Adaptive TTL

Ang TTL ay dinamikong nagbabago depende sa pag-uugali ng data. Halimbawa, kung ang isang record ay bihirang i-update sa server, ang TTL ay tataas; kung madalas i-update — bababa. Ang implementasyon ay maaaring gumamit ng HTTP response headers: ang header na Age (ilang segundo na ang tugon sa cache) at ang header na Date ay nagpapahintulot sa pagkalkula ng natitirang buhay. Ang adaptive TTL ay nagbibigay ng mas mahusay na hit-ratio, ngunit nangangailangan ng karagdagang lohika sa client side.

TTL na may probabilistic expiration

Probabilistic Early Expiration (PEE) — technique kung saan ang TTL ay random na pinipili sa isang tinukoy na range. Ito ay pumipigil sa ‛thundering herd effect“, kapag maraming request ang sabay na nag-e-expire at lahat ng client ay sabay na pumupunta sa pinagmulan. Ang PEE ay lalong kapaki-pakinabang para sa CDN at mga cache na may mataas na load: sa halip na isang solong TTL na 300 segundo, isang random na halaga sa pagitan ng 240 at 360 segundo ang ginagamit, na pantay na namamahagi ng load sa pinagmulan.

Mga halimbawa ng code ng TTL

Tingnan natin ang implementasyon ng cache na may TTL sa Kotlin gamit ang absolute expiration. Ang bawat record ay nag-iimbak ng oras ng paggawa, at sa pagbasa ay sinusuri kung ang TTL ay nag-expire na.

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

Ang klase na Entry ay nag-iimbak ng halaga at oras ng paggawa + TTL (absolute expiration). Ang metodo na get ay sumusuri ng expiration sa bawat access (lazy-cleanup) — ang mga expired na record ay tinatanggal lamang kapag may pagtatangkang i-access ang mga ito. Ang metodo na cleanup ay maaaring tawagin pana-panahon mula sa background thread para sa batch na pagtanggal ng lahat ng lumang record. Ang ConcurrentHashMap ay nagsisiguro ng thread safety nang hindi blino-block ang buong cache.

Halimbawa: TTL para sa pag-cache ng mga tugon ng API sa iOS

Sa iOS, para sa caching na may TTL ay maginhawang gamitin ang URLCache na may configuration na memoryCapacity at diskCapacity. Gayunpaman, ang URLCache ay hindi sumusuporta ng indibidwal na TTL para sa iba't ibang request. Tingnan natin ang custom na wrapper ng NSCache na may suporta sa 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
}

Sa implementasyong ito, ang NSCache ay ginagamit bilang thread-safe na imbakan. Ang CacheEntry ay naglalaman ng Data at expirationDate. Sa get, sinusuri kung ang oras ay nag-expire na; kung nag-expire na — ang record ay tatanggalin at ang nil ay ibabalik. Ang TTL ay itinatakda sa mga segundo sa pamamagitan ng TimeInterval at maaaring magkaiba para sa bawat URL: karaniwang halaga para sa mga tugon ng API ay 120 segundo para sa dinamikong nilalaman at 3600 para sa static na data.