TTL: یہ کیا ہے، کیش کی زندگی کا وقت اور یہ کیسے کام کرتا ہے

TTL کیا ہے؟

TTL (Time To Live) ایک ٹائم اسٹیمپ یا وقفہ ہے جس کے بعد ڈیٹا کو غلط سمجھا جاتا ہے۔ کیشنگ کے سیاق و سباق میں، TTL یہ طے کرتا ہے کہ ایک ریکارڈ ماخذ سے دوبارہ لینے سے پہلے کیش میں کتنی دیر رہ سکتا ہے۔ نیٹ ورک پروٹوکولز میں، TTL پیکٹ کی زندگی کو محدود کرتا ہے، لامحدود روٹنگ کو روکتا ہے۔

TTL ویلیو ہمیشہ وقت کی اکائیوں میں ظاہر کی جاتی ہے: ملی سیکنڈ، سیکنڈ، منٹ یا گھنٹے۔ مقررہ وقت گزرنے کے بعد، ریکارڈ کو کیش سے حذف کر دیا جاتا ہے یا پرانا نشان زد کیا جاتا ہے۔ پرانے ریکارڈ کی اگلی درخواست پر، سسٹم یا تو بعد میں اپ ڈیٹ کے ساتھ پرانا ڈیٹا واپس کر سکتا ہے (stale-while-revalidate) یا تازہ ڈیٹا ملنے تک درخواست کو روک سکتا ہے۔

TTL کا انتخاب ہمیشہ ڈیٹا کی تازگی اور کارکردگی کے درمیان ایک سمجھوتہ ہوتا ہے۔ بہت چھوٹا TTL (1–5 سیکنڈ) ایپلیکیشن کو بار بار نیٹ ورک کی درخواستیں کرنے پر مجبور کرتا ہے، کیشنگ کے فائدے کو ختم کر دیتا ہے۔ بہت لمبا TTL (گھنٹے/دن) صارف کو پرانی معلومات دکھانے کا خطرہ بڑھاتا ہے۔ بہترین قدر ڈیٹا کی قسم پر منحصر ہے: زر مبادلہ کی شرحیں — سیکنڈ، موسم — منٹ، API ورژن — گھنٹے۔

TTL اور کیش کو باطل کرنا

TTL غیر فعال بطلان ہے: ڈیٹا ایک مدت کے بعد خود بخود ہٹا دیا جاتا ہے۔ متبادل فعال بطلان ہے، جہاں ڈیٹا کا ماخذ کیش کو تبدیلیوں کے بارے میں مطلع کرتا ہے (مثال کے طور پر، WebSocket پیغامات یا پش اطلاعات کے ذریعے)۔ 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 کو ایک مخصوص حد کے اندر تصادفی طور پر منتخب کیا جاتا ہے۔ یہ “تھنڈرنگ ہرڈ” اثر کو روکتا ہے، جہاں بہت سی درخواستیں بیک وقت ختم ہو جاتی ہیں اور تمام کلائنٹ بیک وقت ماخذ تک رسائی حاصل کرتے ہیں۔ 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 ہیں۔