Cache Eviction: LRU, LFU ও TTL-এর ভূমিকা
LRU, LFU, TTL, and Cache Eviction
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- Expiration ও eviction-এর পার্থক্য
- LRU, LFU ও admission/size constraints
- Redis maxmemory policy ও workload isolation
সমস্যা দিয়ে শুরু
সব product key-এর TTL দশ মিনিট, কিন্তু মাত্র এক মিনিট পরেই কিছু key miss হচ্ছে। Redis memory full হয়ে keys evict করছে। TTL মানে value দশ মিনিট অবশ্যই থাকবে নয়। Cache lifetime plan-এ expiry, capacity pressure এবং data reconstructability আলাদা বুঝতে হয়।
সহজ করে বুঝি
Expiration সময়সীমা পেরোনো value সরায়। Eviction capacity policy অনুযায়ী value আগে সরাতে পারে। LRU recently unused item victim হিসেবে পছন্দ করে; LFU কম frequency-এর item বেছে নিতে চেষ্টা করে। Redis implementation approximate algorithms ব্যবহার করে, exact global perfect order নয়। allkeys policy সব eligible data-তে, volatile policy TTL থাকা keys-এ প্রয়োগ হতে পারে। noeviction memory pressure-এ new allocating write reject করতে পারে; read failure-free guarantee নয়।
পরিচিত একটি উপমা
কাউন্টারের ছোট shelf-এ নতুন বই রাখতে পুরোনো বই সরাতে হয়। LRU-তে অনেকক্ষণ কেউ না চাওয়া বই, LFU-তে কম জনপ্রিয় বই সরতে পারে। Expiry হলো publisher-এর নির্ধারিত পুরোনো edition-এর শেষ দিন। Shelf ছোট হলে সেই দিনের আগেও বই সরতে পারে।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart TD
W[Cache write] --> M{Memory budget exceeded}
M -->|No| P[Store value with TTL]
M -->|Yes| E{Configured policy}
E --> L[Choose eligible LRU or LFU victim]
E --> N[Reject allocation under noeviction]
L --> P
P --> X[Expire later or evict earlier]Memory budget অতিক্রম করলে policy অনুযায়ী eligible victim খোঁজা হয় বা write reject হতে পারে। TTL expiry পরে ঘটতে পারে, কিন্তু eviction আগে হতে পারে। Application get miss source থেকে rebuild করবে। Queue/lock/session data একই eviction domain-এ থাকলে disposable product cache-এর চাপ অন্য workload correctness affect করতে পারে।
PHP ও Laravel-এ প্রয়োগ
Laravel service fragment cache read miss tolerate করে। Redis maxmemory ও eviction policy server deployment configuration; application request-এ CONFIG SET করবেন না। Product model public, Redis client configured। Outage fallback এবং source rate protection production-এ আলাদা policy দরকার।
use App\Models\Product;
use Illuminate\Support\Facades\Cache;
$key = "product:v3:{$productId}";
$product = Cache::store('redis')->get($key);
if ($product === null) {
$product = Product::query()->findOrFail($productId)->only(['id', 'name']);
Cache::store('redis')->put($key, $product, 600);
}
return response()->json($product);সুবিধা, সীমাবদ্ধতা ও trade-off
LRU shifting working set-এ useful, LFU stable popularity-তে useful হতে পারে। Scan workload many one-off keys দিয়ে useful cache pollute করতে পারে। Large object একটি key হলেও memory বেশি খায়; object size limit/admission policy দরকার। noeviction data silently eviction হওয়া আটকাতে পারে, কিন্তু full memory write errors application handle করবে। Durability বা queue correctness শুধু policy দিয়ে সম্পূর্ণ হয় না।
সাধারণ ভুল
- TTL-কে guaranteed residence time বলা।
- Cache, jobs ও lock data একই unlimited key space-এ মেশানো।
- Hit ratio বাড়াতে oversized value জমিয়ে overall memory pressure বাড়ানো।
আরও একটু গভীরে
Redis memory accounting-এ allocator overhead, fragmentation, replication buffers ও persistence operations-এর headroom গুরুত্বপূর্ণ। maxmemory host RAM-এর সমান রাখলে process/OS চাপ বাড়তে পারে। Metrics হিসেবে evicted_keys, expired_keys, hit/miss, rejected writes, memory ও source query surge দেখুন। Eviction spikes-এর পরে source overload হলে cache optimization system failure trigger করছে; concurrency cap/stampede policy পরীক্ষা করুন।
মনে রাখুন
TTL freshness boundary, memory residence guarantee নয়। Eviction workload অনুযায়ী configure করুন। Cache miss ও write failure normal operational path হিসেবে design করুন।
নিজে চেষ্টা করুন
Staging Redis-এ ছোট memory budget ও representative size values দিয়ে eviction observe করুন। Long TTL থাকলেও early miss count করুন। LRU/LFU comparison-এ একই traffic trace ব্যবহার করুন এবং queue/production Redis-এ experiment করবেন না।
নিজের বোঝা যাচাই করুন
1. TTL শেষের আগে miss?
Eviction, explicit invalidation বা restart-এর কারণে হতে পারে। TTL maximum freshness intent, guaranteed minimum lifetime নয়।
2. LRU আর LFU?
LRU recent use, LFU frequency signal দেখে victim বেছে নিতে চেষ্টা করে। Actual Redis approximation ও workload ফল নির্ধারণ করে।
3. volatile policy সব key?
না। TTL-bearing eligible keys subset ব্যবহার করতে পারে। Eligible victim না থাকলে behavior configured policy অনুযায়ী বুঝতে হবে।
4. noeviction সব ঠিক রাখে?
Write allocation reject হতে পারে এবং restart/replication durability আলাদা। Application errors ও capacity management দরকার।
5. কী monitor করব?
Eviction/expiry count, memory, rejected writes এবং source load। Hit ratio একা correctness ও pressure বোঝায় না।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।