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 जाँच को ऑप्टिमाइज़ करने के लिए, अनुसूचित सफाई (सभी समाप्त रिकॉर्ड का आवर्तिक हटाना) या आलसी सफाई (केवल रिकॉर्ड तक पहुँचने पर ही हटाना) का उपयोग किया जा सकता है। आलसी सफाई मेमरी में अधिक कुशल है क्योंकि इसे पूरे कैश को स्कैन करने के लिए पृष्ठभूमि थ्रेड की आवश्यकता नहीं होती।

वितरित सिस्टम में, TTL का उपयोग स्वचालित विरोध समाधान के लिए भी किया जाता है। उदाहरण के लिए, यदि दो सर्वर एक ही की के लिए अलग-अलग मान लिखते हैं, तो बाद के TTL वाले रिकॉर्ड को उच्च प्राथमिकता दी जा सकती है। Amazon DynamoDB तालिकाओं में पुराने रिकॉर्ड को स्वचालित रूप से हटाने के लिए TTL का उपयोग करता है — यह एक निर्मित सुविधा है जिसके लिए मैनुअल प्रबंधन की आवश्यकता नहीं है।

पुराना पढ़ने की रणनीतियाँ

TTL समाप्त होने पर प्रदर्शन में सुधार के लिए, पुराना पढ़ने की रणनीतियों का उपयोग किया जाता है। Stale-while-revalidate — तुरंत ग्राहक को पुराना डेटा लौटाएँ और साथ ही पृष्ठभूमि अपडेट शुरू करें। Stale-if-error — यदि स्रोत अस्थायी रूप से अनुपलब्ध हो तो पुराना डेटा लौटाएँ। Cache-Aside (Lazy Loading) — कैश मिस होने पर, स्रोत से डेटा लोड करें, एक नए TTL के साथ कैश में सहेजें, और तब ही इसे ग्राहक को लौटाएँ। प्रत्येक रणनीति डेटा संगति आवश्यकताओं के आधार पर चुनी जाती है।

डेटा कैशिंग में TTL

मोबाइल एप में, TTL कैश प्रबंधन के लिए एक महत्वपूर्ण तंत्र है। आइए मुख्य परिदृश्यों को देखें जहां TTL एप के व्यवहार और उपयोगकर्ता अनुभव को निर्धारित करता है।

HTTP प्रतिक्रियाओं को कैश करना

HTTP प्रोटोकॉल Cache-Control हेडर के माध्यम से एक निर्मित TTL तंत्र प्रदान करता है। max-age निर्देश TTL को सेकंड में सेट करता है: Cache-Control: public, max-age=3600 का अर्थ है कि प्रतिक्रिया को 1 घंटे के लिए कैश किया जा सकता है। अतिरिक्त निर्देश s-maxage (साझा कैश के लिए, जैसे CDN) और stale-while-revalidate अधिक सूक्ष्म नियंत्रण प्रदान करते हैं। जब TTL expires हेडर के साथ मेल खाता है, तो max-age को अधिक आधुनिक HTTP/1.1 मानक के रूप में प्राथमिकता दी जाती है।

छवियों को कैश करना

छवियों के लिए, TTL कई दिनों तक पहुँच सकता है क्योंकि सामग्री शायद ही बदलती है। हालांकि, मोबाइल एप अक्सर एक हाइब्रिड दृष्टिकोण का उपयोग करते हैं: पूर्वावलोकन के लिए छोटा TTL (30 मिनट — फ़्रेम ताजगी) और पूर्ण आकार की छवियों के लिए लंबा TTL (7 दिन)। HTTP हेडर Cache-Control: immutable वाली छवियों को TTL समाप्त होने तक पुनः अनुरोधित नहीं किया जाना चाहिए — यह RFC 8246 में प्रस्तावित स्थिर संसाधनों के लिए एक ऑप्टिमाइजेशन है। ऐसी छवियाँ OS स्तर (URLCache, OkHttp Cache) पर एप की भागीदारी के बिना कैश की जाती हैं।

नेटवर्क प्रोटोकॉल में TTL

नेटवर्क में, TTL का उपयोग कैशिंग के लिए नहीं बल्कि पैकेट के जीवनकाल को सीमित करने के लिए किया जाता है। प्रत्येक IP पैकेट में एक TTL फ़ील्ड (8 बिट) होता है, जो प्रत्येक रूटर द्वारा 1 घटा दिया जाता है। जब TTL 0 तक पहुँचता है, पैकेट को खारिज कर दिया जाता है, और भेजने वाले को ICMP Time Exceeded संदेश भेजा जाता है। यह नेटवर्क लूप के दौरान अनंत रूटिंग को रोकता है।

DNS में TTL

DNS रिकॉर्ड में TTL होता है जो यह निर्धारित करता है कि एक रिज़ॉल्वर (उदाहरण के लिए, ISP DNS कैश) प्रामाणिक सर्वर से पूछे बिना रिकॉर्ड को कितने समय तक संग्रीहीत कर सकता है। विशिष्ट मान: बार-बार बदलने वाले रिकॉर्ड के लिए 300 सेकंड (5 मिनट), स्थिर डोमेन के लिए 86400 सेकंड (24 घंटे)। CDN सेवाएँ अक्सर विफलताओं के दौरान त्वरित ट्रैफिक पुनर्निर्देशन के लिए कम TTL (60–300 सेकंड) निर्धारित करती हैं, जबकि स्थिर डोमेन का TTL 7 दिनों तक हो सकता है। सर्वर माइग्रेशन करते समय, पहले TTL को 60 सेकंड (48 घंटे पहले) कम करने की सिफारिश की जाती है ताकि परिवर्तन तेजी से फैल सकें।

सत्र और टोकन में TTL

मोबाइल एप में, TTL का उपयोग सत्र और एक्सेस टोकन के प्रबंधन के लिए किया जाता है। JWT टोकन (JSON Web Tokens) में एक exp (समाप्ति समय) फ़ील्ड होता है, जो एक निरपेक्ष Unix समाप्ति समय है। समाप्ति के बाद, बिना पुनः प्रमाणीकरण के एक नया एक्सेस टोकन प्राप्त करने के लिए रिफ़्रेश टोकन का उपयोग किया जाता है। एक्सेस टोकन TTL आमतौर पर 1–24 घंटे, रिफ़्रेश टोकन TTL 7–30 दिन होता है। यह सुरक्षा (छोटा TTL लीक के जोखिम को कम करता है) और UX (लंबा TTL पुनः लॉगिन की आवृत्ति कम करता है) के बीच एक संतुलन है।

TTL चयन रणनीतियाँ

TTL चुनना एक इंजीनियरिंग निर्णय है जो डेटा प्रकार, ताजगी SLA और पुनः अनुरोध की लागत पर निर्भर करता है। आइए मुख्य रणनीतियों पर नज़र डालें।

निश्चित TTL

सबसे सरल दृष्टिकोण — सभी रिकॉर्ड का एक ही TTL होता है। उदाहरण के लिए, सभी API प्रतिक्रियाओं को 5 मिनट के लिए कैश करें। लाभ: सरलता और पूर्वानुमानीय व्यवहार। कमी: विभिन्न डेटा प्रकारों की अलग-अलग परिवर्तन आवृत्ति को ध्यान में नहीं लेता। निश्चित TTL समान डेटा के लिए उचित है जहां सभी रिकॉर्ड की ताजगी समान हो — उदाहरण के लिए, एक एक्सचेंज पर क्रिप्टोकरेंसी दरें।

अनुकूली TTL

TTL डेटा के व्यवहार के आधार पर गतिशील रूप से बदलता है। उदाहरण के लिए, यदि कोई रिकॉर्ड सर्वर पर शायद ही अपडेट होता है, TTL बढ़ जाता है; यदि यह बार-बार अपडेट होता है — घट जाता है। कार्यान्वयन HTTP प्रतिक्रिया हेडर का उपयोग कर सकता है: Age हेडर (प्रतिक्रिया कैश में कितने सेकंड से है) और Date हेडर शेष जीवनकाल की गणना की अनुमति देते हैं। अनुकूली TTL बेहतर हिट अनुपात प्रदान करता है लेकिन क्लाइंट पर अतिरिक्त तर्क की आवश्यकता होती है।

संभाव्यता के साथ TTL समाप्ति

Probabilistic Early Expiration (PEE) — एक तकनीक जहां TTL को एक निर्दिष्ट सीमा के भीतर यादृच्छिक रूप से चुना जाता है। यह भीड़ के झुंड प्रभाव (thundering herd) को रोकता है, जहां एक साथ अनेक अनुरोध समाप्त हो जाते हैं और सभी क्लाइंट एक साथ स्रोत पर पहुँचते हैं। PEE विशेष रूप से CDN और उच्च-भार कैश के लिए उपयोगी है: 300 सेकंड के एकल TTL के बजाय, 240 से 360 सेकंड का एक यादृच्छिक मान उपयोग किया जाता है, जो स्रोत पर भार को समान रूप से वितरित करता है।

TTL कोड उदाहरण

आइए निरपेक्ष समाप्ति का उपयोग करके Kotlin में TTL के साथ एक कैश कार्यान्वयन देखें। प्रत्येक रिकॉर्ड अपना निर्माण समय संग्रीहीत करता है, और पढ़ते समय जाँचा जाता है कि 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 विधि प्रत्येक पहुँच पर समाप्ति की जाँच करती है (आलसी सफाई) — समाप्त रिकॉर्ड केवल तब हटाए जाते हैं जब उन तक पहुँचने का प्रयास किया जाता है। सभी पुराने रिकॉर्ड को एक साथ हटाने के लिए cleanup विधि को पृष्ठभूमि थ्रेड से समय-समय पर बुलाया जा सकता है। ConcurrentHashMap पूरे कैश को लॉक किए बिना थ्रेड सुरक्षा प्रदान करता है।

उदाहरण: iOS पर API प्रतिक्रियाओं को कैश करने के लिए TTL

iOS में, TTL के साथ कैशिंग के लिए memoryCapacity और diskCapacity सेटिंग के साथ URLCache का उपयोग करना सुविधाजनक है। हालांकि, URLCache विभिन्न अनुरोधों के लिए अलग-अलग TTL का समर्थन नहीं करता है। आइए TTL समर्थन के साथ एक कस्टम NSCache रैपर पर विचार करें।

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 हैं।