পাঠ্যক্রম খুলুন

মধ্যবর্তী পর্যায়

Hot Key ও Cache Penetration: traffic ও miss-এর চাপ

Hot Keys and Cache Penetration

এই পাঠের কুইজ ↓৬ মিনিট পড়াPHP 8.3+ · Laravel 12

আগে পড়ে নিনCache-aside: Laravel ও Redis-এ cache ব্যবহার ↗Vertical ও Horizontal Scaling: সার্ভার বড় করব, না বাড়াব ↗

এই পাঠের সূচিপত্র

এই পাঠে যা শিখবেন

Hot key, cache penetration ও avalanche আলাদা করা
Negative caching ও bounded inputs
Local cache ও key replication-এর trade-off

সমস্যা দিয়ে শুরু

একটি viral product-এর key এক Redis node-এ প্রচুর traffic নিচ্ছে। একই সময়ে bot লক্ষ ভুয়া product ID চায়; প্রতিবার cache miss থেকে database query হয়। প্রথমটি hit হলেও hotspot, দ্বিতীয়টি absent data-র penetration। সব cache সমস্যা expiry নয়; traffic shape ও key cardinality দেখতে হবে।

সহজ করে বুঝি

Hot key একটি identity-তে concentrated access। Cache penetration-এ repeated nonexistent বা uncacheable lookup source store-এ যায়। Cache avalanche অনেক key বা পুরো cache একসঙ্গে হারিয়ে source overload করে। Negative caching ছোট সময়ের জন্য “not found” result রাখে, কিন্তু পরে নতুন resource তৈরি হলে stale absence হতে পারে। Per-request validation, rate limiting ও bounded key space source protection-এর অংশ। Bloom filter candidate absent জানাতে পারে, তবে false positive থাকে এবং membership update দরকার।

পরিচিত একটি উপমা

এক জনপ্রিয় বইয়ের shelf-এর সামনে ভিড় hot key। নেই এমন বইয়ের জন্য বারবার warehouse খোঁজা penetration। সব shelf একসঙ্গে খালি হওয়া avalanche। “এই বই এখন নেই” ছোট তালিকা lookup বাঁচায়, কিন্তু নতুন stock এলে তালিকা বদলাতে হয়।

নকশাটি দেখুন

Diagram লোড হচ্ছে…

Validation absurd input source query-এর আগে আটকায়, তবে valid integer nonexistent হতে পারে।

Diagram-এর text flow দেখুন

flowchart TD
 R[Product request] --> V[Validate bounded ID]
 V --> C{Cache lookup}
 C -->|Found marker| N[Return 404]
 C -->|Data| O[Return product]
 C -->|Miss| D[(Database lookup)]
 D --> P[Store data or short negative marker]
 P --> C

Validation absurd input source query-এর আগে আটকায়, তবে valid integer nonexistent হতে পারে। Cache-এ found marker বা data envelope রাখা হয়। Database miss short-lived negative marker দেয়। Product create হলে corresponding key invalidate করতে হবে। Diagram loop logical re-read বোঝায়; নিচের code একই loaded envelope থেকে response দেয়, recursive request চালায় না।

PHP ও Laravel-এ প্রয়োগ

Controller fragment; productId positive bounded integer হিসেবে validated। Public product fields-ই রাখা হয়েছে; Redis configured। Negative entry ১৫ সেকেন্ড, found entry ১২০ সেকেন্ড রাখা হচ্ছে illustrative policy হিসেবে। Concurrent miss coordination এই snippet-এ নেই।

use App\Models\Product;
use Illuminate\Support\Facades\Cache;

$cache = Cache::store('redis');
$key = "product:v1:{$productId}";
$entry = $cache->get($key);
if ($entry === null) {
    $product = Product::query()->find($productId);
    $entry = [
        'found' => $product !== null,
        'data' => $product?->only(['id', 'name']),
    ];
    $cache->put($key, $entry, $entry['found'] ? 120 : 15);
}
abort_unless($entry['found'], 404);
return response()->json($entry['data']);

সুবিধা, সীমাবদ্ধতা ও trade-off

Negative cache repeated absent lookup কমায়, কিন্তু unbounded random IDs cache memory-ও ভরতে পারে। Input limit, endpoint rate limit ও maximum cardinality বিচার করুন। Local per-process cache network hot key load কমায়, কিন্তু instance অনুযায়ী stale copy ও memory duplication বাড়ে। Key replication read distribute করতে পারে, তবে update fan-out ও consistency জটিল; শুধু key suffix random করলেই solution নয়।

সাধারণ ভুল

Not-found result null রেখে null-কে miss হিসেবেই পড়া।
Attack traffic-এর প্রতিটি arbitrary input cache করা।
Redis cluster hot key নিজে ভাগ করে দেবে ভাবা।

আরও একটু গভীরে

এক key একটি shard-এ map হলে shard count বাড়ানো সেই key-এর load ভাগ করে না। Read replicas কিছু read load নিতে পারে, কিন্তু replication lag ও client routing গুরুত্বপূর্ণ। Heavy hitter metrics-এ raw key customer identity leak করতে পারে; sampled/hardened labels ব্যবহার করুন। Product authorization failure এবং absence একই negative cache key-তে রাখলে user-specific access ভুল share হতে পারে। Public existence ও private authorization আলাদা cache contract রাখুন।

মনে রাখুন

Hit ratio একা যথেষ্ট নয়; per-key concentration ও miss reason দেখুন। Negative caching-এ envelope ও short lifetime ব্যবহার করুন। Cardinality এবং source protection একসঙ্গে ভাবুন।

নিজে চেষ্টা করুন

একটি absent ID একশবার এবং একশ আলাদা absent ID একবার করে request করুন। Database query ও cache key count তুলনা করুন। তারপর product create করে negative cache invalidation না হলে user কতক্ষণ 404 দেখবেন ব্যাখ্যা করুন।

নিজের বোঝা যাচাই করুন

1. Hot key-তে cache hit থাকে?

হ্যাঁ। একটি value প্রচুর read হলে source বাঁচলেও cache node saturated হতে পারে। Hit ratio তাই hotspot অস্বীকার করে না।

2. Negative marker কেন?

Null-কে cache miss ধরা হলে absent result reuse হবে না। Explicit found=false envelope absence-কে cacheable value করে।

3. Shard বাড়ালেই hotspot যাবে?

এক key সাধারণত এক shard-এ যায়। Key-level concentration partition count দিয়ে স্বয়ংক্রিয়ভাবে ভাগ হয় না।

4. Negative TTL দীর্ঘ রাখব?

Load কমবে, কিন্তু নতুন resource কিছুক্ষণ nonexistent দেখাতে পারে। Create invalidation ও freshness requirement অনুযায়ী lifetime ঠিক করুন।

5. Bloom filter কি exact?

সাধারণ Bloom filter false positive দিতে পারে; definitely absent ও possibly present আলাদা ফল। Deletion/update strategy ছাড়া authoritative membership ধরে নেবেন না।

এই পাঠের কুইজ

এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।

এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।

জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।

সব বিষয় মিলিয়ে অনুশীলন করুন →

অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।