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 সমজাতীয় ডেটার জন্য ন্যায়সঙ্গত যেখানে সমস্ত রেকর্ডের একই “sতেজতা” থাকে — উদাহরণস্বরূপ, একটি এক্সচেঞ্জে ক্রিপ্টোকারেন্সির হার।

অভিযোজিত 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-এ, memoryCapacity এবং diskCapacity সেটিংস-সহ URLCache ব্যবহার করা TTL-সহ ক্যাশিংয়ের জন্য সুবিধাজনক। তবে, 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।