Cache — Redis, cache-aside আর invalidation

১ · Cache কেন, আর কোন স্তরে

বাজারঘরের একটি পণ্যের পাতা খুলতে ডেটাবেসকে কয়েকটি কাজ করতে হয়: পণ্যের তথ্য, রেটিংয়ের হিসাব, শেষ পাঁচটি রিভিউ, আর ওই category-র সেরা চারটি পণ্য। একই পাতা দিনে হাজারবার খোলে, অথচ ডেটা বদলায় দিনে দুবার। প্রতিবার সব নতুন করে হিসাব করা অপচয়।

তাক একটি নয়, কয়েকটি। একটি অনুরোধ ক্রেতার ফোন থেকে ডেটাবেস পর্যন্ত যাওয়ার পথে অন্তত পাঁচ জায়গায় থামতে পারে।

ওপরের দুটি স্তর চলে HTTP দিয়ে। পর্ব ৩৩-এ (Status code আর error format) আমরা ETag আর 304 দেখেছি, আর Cache-Control header বলে দেয় কে কতক্ষণ জমাতে পারবে। Browser-এর ভেতরের server state cache পর্ব ১৯-এ (TanStack Query) আছে। এই পর্ব server-এর ভেতরের দুই স্তর নিয়ে। পুরো সিস্টেমের হিসাবে caching-এর তত্ত্ব আছে Caching কৌশল পর্বে। এখানে আমরা সেটি বাজারঘরে বসাব, চালাব আর ভাঙব।

২ · আগে মাপুন, তারপর cache

Cache যোগ করলে নতুন একটি server, নতুন ব্যর্থতা আর পুরোনো ডেটার ঝুঁকি আসে। তাই প্রথম কাজ মাপা। এই পর্বের সব পরীক্ষা চলেছে একটি আসল ল্যাবে: Express 5.3.0, PostgreSQL 18.6 (npm-এর বহনযোগ্য embedded-postgres), Redis 8.10.3 আর Node.js 24.15. ডেটায় আছে ৫০,০০০ পণ্য আর ১০ লাখ রিভিউ।

প্রথমে একটি সস্তা পাতা: সব query index-এ চলে। একই ক্রমে ২০,০০০ অনুরোধ, একটির পর একটি, প্রথমে cache ছাড়া, পরে cache-সহ। জনপ্রিয় পণ্য বেশি আসে, বাস্তবের মতো (Zipf বণ্টন)।

সত্যিকারের run · একটি local কম্পিউটারে একবার · সব একই যন্ত্রে, network নেই · সস্তা পাতা · ~/bazarghar · উত্তর ছাঁটা

NO CACHE   db calls 20000 avg 0.244 ms  p50 0.215 ms  p95 0.371 ms
CACHE      db calls 6670  hits 13330  misses 6670  rate 66.7%
  hit  avg 0.100 ms  p50 0.097 ms
  miss avg 0.508 ms  p50 0.487 ms
  all  avg 0.236 ms  p50 0.109 ms  p95 0.571 ms
keyspace_hits:13330  keyspace_misses:6670

ফলটি অনেককে অবাক করে। গড় সময় প্রায় বদলায়নি, আর p95 উল্টো খারাপ হয়েছে। কেন? Cache miss-এ তিনটি কাজ হয়: Redis দেখা, ডেটাবেসে যাওয়া, Redis-এ লেখা। তাই miss (০.৫০৮ ms) cache ছাড়া পড়ার (০.২৪৪ ms) দ্বিগুণের বেশি। Cache hit-এর লাভ এই ক্ষতি কোনোমতে পুষিয়েছে।

সমতার বিন্দু — একটি পূর্ণ numerical

ধরুন h হলো hit rate, G মানে Redis থেকে পড়া, L মানে ডেটাবেস থেকে আনা, S মানে Redis-এ লেখা। Hit-এ শুধু G লাগে, miss-এ G + L + S.

মাপা মান বসাই: G = ০.১০০, L = ০.২৪৪, আর S = ০.৫০৮ − ০.১০০ − ০.২৪৪ = ০.১৬৪ ms. সমতার বিন্দু h = (০.১০০ + ০.১৬৪) / (০.২৪৪ + ০.১৬৪) = ০.২৬৪ / ০.৪০৮ ≈ ৬৪.৭%. আমাদের hit rate ছিল ৬৬.৭%, মানে সীমার ঠিক ওপরে। সূত্রে গড় = ০.১০০ + ০.৩৩৩ × ০.৪০৮ ≈ ০.২৩৬ ms, যা মাপা ফলের সাথে মিলে গেল।

এবার ভারী পাতা। “এই category-র সেরা ৪টি পণ্য” বের করতে প্রায় ১.২৫ লাখ রিভিউ join করে গড় নিতে হয়। এবার আসল Express সার্ভারে, ১৬টি সংযোগ একসাথে, ৬,০০০ অনুরোধ।

সত্যিকারের run · একটি local কম্পিউটারে একবার · cache খালি থেকে শুরু, তাই hit rate ৫৬% · এটি সাধারণ ফল নয়

ভারী পাতায় throughput দ্বিগুণের বেশি, আর মধ্যম ক্রেতার সময় ১৭৫ গুণ কম। p95 প্রায় একই থাকল, কারণ এখনো অনেক miss আছে। সময় যত গেল, cache ভরল। একই বণ্টনে পরপর চারটি দফায় ডেটাবেসের কাজ কমেছে:

সত্যিকারের run · ভারী পাতা · প্রতি দফায় ৬,০০০টি নতুন অনুরোধ · TTL ৬০০ সেকেন্ড · উত্তর ছাঁটা

pass 1: 195 req/s hit 3379 miss 2621 rate 56.3% avg 81.851 ms p50 1.407 ms
pass 2: 273 req/s hit 4096 miss 1904 rate 68.3% avg 58.375 ms p50 0.930 ms
pass 3: 325 req/s hit 4343 miss 1657 rate 72.4% avg 48.996 ms p50 0.738 ms
pass 4: 369 req/s hit 4494 miss 1506 rate 74.9% avg 43.192 ms p50 0.696 ms

৩ · Redis: key, string, hash, sorted set আর TTL

Redis হলো একটি সার্ভার, যা ডেটা মেমরিতে রাখে আর network-এ command শোনে। Salvatore Sanfilippo (antirez) এটি ২০০৯ সালে প্রকাশ করেন। প্রতিটি মানের একটি নাম থাকে, আর সেই নাম দিয়েই মান পাওয়া যায়। হোটেলের রিসেপশনের চাবির বোর্ডের মতো: ঘরের নম্বর জানলে এক হাতেই চাবি মেলে, পুরো হোটেল খুঁজতে হয় না।

এই ল্যাবে Docker ছাড়াই চলেছে Redis 8.10.3-এর একটি Windows build (redis-windows নামের community প্রকল্পের, প্রকাশিত SHA-256 মিলিয়ে নেওয়া)। এটি Redis-এর সরকারি build নয়। Linux-এ আপনার distribution-এর package বা Docker Compose বেশি প্রচলিত পথ, যদিও এই ল্যাবে সেগুলো চালানো হয়নি।

সত্যিকারের run · Redis 8.10.3 · redis-cli · > দিয়ে শুরু লাইন command, বাকিগুলো Redis-এর উত্তর · কিছু লাইন বাদ

$ redis-server --port 38441 --bind 127.0.0.1 --save "" --appendonly no

> SET shop:v1:product:7 "{\"id\":7,\"price\":320}" EX 300
OK
> GET shop:v1:product:7
"{\"id\":7,\"price\":320}"
> TTL shop:v1:product:7
(integer) 300
> HSET cart:u42 sku-7 2 sku-9 1
(integer) 2
> HINCRBY cart:u42 sku-7 1
(integer) 3
> HGETALL cart:u42
1) "sku-7"
2) "3"
3) "sku-9"
4) "1"
> ZADD top:sold 150 sku-7 90 sku-9 210 sku-3
(integer) 3
> ZINCRBY top:sold 5 sku-9
"95"
> ZREVRANGE top:sold 0 1 WITHSCORES
1) "sku-3"
2) "210"
3) "sku-7"
4) "150"
> TTL no:such:key
(integer) -2

TTL (Time To Live) মানে কত সেকেন্ড পরে key নিজে মুছে যাবে। TTL command-এর উত্তরে দুটি বিশেষ মান আছে: -1 মানে key আছে কিন্তু মেয়াদ নেই, আর -2 মানে key-ই নেই। Cache-এ TTL ছাড়া key রাখা ভুল, কারণ invalidation কখনো ফসকালে সেই ভুল মান চিরকাল থাকে। TTL হলো শেষ রক্ষাকবচ।

আসল client: redis

Node.js-এ দুটি জনপ্রিয় package আছে: redis (node-redis, লেখার সময়ে 6.3.1) আর ioredis (6.0.0). Redis-এর docs node-redis-কে সুপারিশ করে, আর ioredis-কে পুরোনো কিন্তু সমর্থিত client বলে। এই পর্বে node-redis চলেছে।

import { createClient } from 'redis';

export const redis = createClient({ url: process.env.REDIS_URL });

// এই listener না থাকলে সংযোগের error-এ process পড়ে যায়
redis.on('error', (err) => log.warn({ err }, 'redis error'));

await redis.connect();

Redis-এর আরও দুটি কাজ: session আর rate limit

একই সার্ভার শুধু cache নয়। পর্ব ৪৫-এ session-ভিত্তিক login-এর store হিসেবে Redis আসবে, আর পর্ব ৪৯-এ rate limit. Counter-এর ধরনটি দেখে নিন, কারণ এর একটি ফাঁদ আছে।

সত্যিকারের run · Redis 8.10.3 · প্রতি IP-তে ৬০ সেকেন্ডের counter · 1.2.3.4 একটি উদাহরণ ঠিকানা

> SET ratelimit:1.2.3.4 0 EX 60 NX
OK
> INCR ratelimit:1.2.3.4
(integer) 1
> INCR ratelimit:1.2.3.4
(integer) 2
> TTL ratelimit:1.2.3.4
(integer) 60
> SET sess:abc123 "{\"userId\":42}" EX 1800
OK
> EXPIRE sess:abc123 1800
(integer) 1

INCR একা ব্যবহার করে পরে আলাদা EXPIRE দিলে মাঝখানে process পড়ে গেলে counter চিরকাল থেকে যায়। SET … EX 60 NX আগে ডাকলে সেই ফাঁক থাকে না, কারণ মান আর মেয়াদ একই command-এ বসে। Session-এ প্রতি অনুরোধে EXPIRE দিলে মেয়াদ এগিয়ে যায়। সতর্ক থাকুন: session আর rate limit-এ ডেটা হারালে ফল আলাদা। Cache হারালে শুধু ধীর হয়, session হারালে ক্রেতা logout হন। তাই এই দুই কাজে eviction আর persistence নিয়ে আলাদা সিদ্ধান্ত লাগে।

৪ · Cache-aside: বাজারঘরের পণ্যের পাতা

সবচেয়ে প্রচলিত কৌশলটির নাম cache-aside. Cache পাশে বসে থাকে, আর সব সিদ্ধান্ত নেয় আপনার কোড। Redis ডেটাবেসকে চেনেই না। নিচে একই পণ্য দুবার চাওয়া হলো। ব্যবহৃত সময় আসল run থেকে।

GET /api/products/7
key বানানো হলো: shop:v1:product:7

> GET shop:v1:product:7
(nil)

পণ্য + রেটিং + শেষ ৫ রিভিউ + সেরা ৪ পণ্য
পুরো উত্তর JSON-এ: 1155 byte

> SET shop:v1:product:7 '{…}' EX 300
OK
উত্তর: X-Cache: MISS  173.0 ms

> GET shop:v1:product:7
"{\"id\":7, …}"
উত্তর: X-Cache: HIT  3.0 ms

আসলে চলা কোডের মূল অংশ এটুকুই। id আগেই সংখ্যা হিসেবে যাচাই করা, পর্ব ২৭-এর (Request যাচাই) মতো।

const keyOf = (id) => `shop:v1:product:${id}`;
const TTL = 300;
const ttl = () => Math.round(TTL * (0.9 + Math.random() * 0.2)); // ±10% jitter

async function getProduct(id) {
  const k = keyOf(id);
  const c = await cacheGet(k);                // অংশ ৮-এ এর ভেতরটা দেখব
  if (c !== null) return { src: 'HIT', body: JSON.parse(c) };

  const v = await loadProductPage(id);        // ডেটাবেস
  if (v) await cacheSet(k, JSON.stringify(v), ttl());
  return { src: 'MISS', body: v };
}

app.get('/api/products/:id', async (req, res) => {
  const id = Number(req.params.id);
  if (!Number.isInteger(id) || id < 1) return res.status(400).json({ error: 'bad id' });
  const { src, body } = await getProduct(id);
  res.set('X-Cache', src);
  if (!body) return res.status(404).json({ error: 'not found' });
  res.json(body);
});

সত্যিকারের run · Express 5.3.0, Redis 8.10.3, PostgreSQL 18.6 · একটি local কম্পিউটারে একবার

GET /api/products/7  200  X-Cache: MISS  173.0 ms  1155 byte
GET /api/products/7  200  X-Cache: HIT   4.3 ms  1155 byte
GET /api/products/7  200  X-Cache: HIT   3.0 ms  1155 byte
GET /api/products/8  200  X-Cache: MISS  72.9 ms  1151 byte

X-Cache একটি নিজের বানানো header. এটি ক্রেতার জন্য নয়, আপনার জন্য: log আর metric-এ hit rate দেখা যায়। Redis নিজেও গোনে: INFO stats-এর keyspace_hits আর keyspace_misses. আগের run-এ এই দুটি ছিল 13330 আর 6670, যা আমাদের নিজের গণনার সাথে হুবহু মিলেছে।

নিচের ছোট মডেলে একটি Map হলো নকল Redis, আর ঘড়িটিও নকল, তাই ৩০০ সেকেন্ড অপেক্ষা করতে হয় না। এটি শেখানোর মডেল, আসল Redis নয়। চালিয়ে দেখুন t=121-এর লাইনটি।

// শেখানোর মডেল: Map হলো নকল Redis, আর now একটি নকল ঘড়ি (সেকেন্ড)
let now = 0;
const store = new Map();
const redis = {
  get(k) {
    const e = store.get(k);
    if (!e) return null;
    if (e.exp <= now) { store.delete(k); return null; }   // TTL শেষ
    return e.v;
  },
  set(k, v, ttl) { store.set(k, { v, exp: now + ttl }); },
  del(k) { store.delete(k); },
};
const db = { 7: { price: 320 }, 9: { price: 150 } };
let hits = 0, misses = 0;
function getProduct(id) {
  const k = `shop:v1:product:${id}`;
  const cached = redis.get(k);
  if (cached !== null) { hits++; return { src: 'HIT ', ...JSON.parse(cached) }; }
  misses++;
  const row = db[id];                    // ডেটাবেস থেকে পড়া
  redis.set(k, JSON.stringify(row), 300);
  return { src: 'MISS', ...row };
}
function show(t, id) {
  now = t;
  const p = getProduct(id);
  console.log(`t=${String(t).padStart(3)}  id=${id}  ${p.src}  price=${p.price}`);
}
show(0, 7); show(10, 7); show(11, 9); show(120, 7);
db[7].price = 350;                       // দাম বদলাল, cache জানে না
show(121, 7);
redis.del('shop:v1:product:7');          // invalidation
show(122, 7); show(423, 7);              // ৩০১ সেকেন্ড পরে TTL শেষ
console.log(`hits=${hits} misses=${misses} rate=${(100 * hits / (hits + misses)).toFixed(1)}%`);

৫ · Key-এর নাম, version, jitter আর যা cache করা যাবে না

Key-এর নাম ঠিক করে দুটি জিনিস: কে কার ডেটা পাবে, আর পরে সব মোছা যাবে কীভাবে। আমাদের cache key-এর গঠন:

এখানে v1 মানে JSON-এর আকার। ধরুন নতুন release-এ price সংখ্যা থেকে { amount, currency } হলো। পুরোনো key-গুলো নতুন কোড পড়লে ভাঙবে। Rolling deploy-এর সময় পুরোনো আর নতুন server একসাথে চলে, তাই FLUSHDB করলেও সমস্যা থাকে, কারণ পুরোনো server আবার পুরোনো আকার লিখবে। সমাধান সহজ: নতুন কোড v2 ব্যবহার করবে। দুটি আকার আলাদা নামে থাকে, আর v1-এর key TTL শেষে নিজেই মরে। এ ছাড়া নামে উত্তর যা যা-র ওপর নির্ভর করে তার সবই থাকতে হবে: ভাষা, মুদ্রা, sort, page.

যা একই key-তে রাখা যাবে না

এই নিয়ম ভাঙলে ফল শুধু ধীর নয়, ভয়ংকর। নিচে ইচ্ছা করে লেখা একটি ভুল: /api/bad/me সবার জন্য একটিই key ব্যবহার করে।

সত্যিকারের run · ইচ্ছাকৃত ভুল · ফোন নম্বর কল্পিত

X-User: rahim -> MISS {"user":"rahim","phone":"017xx-xxx-111"}
X-User: karim -> HIT {"user":"rahim","phone":"017xx-xxx-111"}

করিম রহিমের ফোন নম্বর পেলেন। কোনো error নেই, কোনো log নেই। Authentication ঠিক ছিল, আর authorization-ও, কিন্তু cache দুটোর পরে বসে আরেকজনের উত্তর ফিরিয়েছে। ব্যক্তিগত ডেটায় key-তে user id লাগবেই, যেমন shop:v1:cart:u42, আর ওপরের স্তরে Cache-Control: private বা no-store. একই ভুল CDN-এ হলে ক্ষতি আরও বড় (পর্ব ৮৪-এ আসবে)।

TTL-এ jitter

রাতে একটি job ১,০০০টি পণ্য cache-এ ভরল, সবার TTL ৩০০ সেকেন্ড। ঠিক ৩০০ সেকেন্ড পরে সবকটি একসাথে মরবে, আর সব অনুরোধ একই মুহূর্তে ডেটাবেসে ছুটবে। অফিস ছুটির সময় একসাথে সব লিফটে ভিড়ের মতো। Jitter মানে TTL-এ একটু এলোমেলো অংশ যোগ করা, যাতে মেয়াদ ছড়িয়ে পড়ে। আমাদের কোডের ttl() ঠিক এই কাজই করে।

// শেখানোর মডেল: ১০০০টি key একই মুহূর্তে লেখা, ঘড়ি নকল, PRNG বীজ-নির্ভর
function mulberry32(a) {
  return () => {
    a = (a + 0x6D2B79F5) | 0;
    let t = Math.imul(a ^ (a >>> 15), 1 | a);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
    return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
  };
}
const KEYS = 1000, TTL = 300;
function peak(jitterPct) {
  const rnd = mulberry32(44);
  const perWindow = new Map();                  // ১০ সেকেন্ডের ঘর
  for (let i = 0; i < KEYS; i++) {
    const spread = TTL * jitterPct / 100;
    const ttl = TTL - spread + rnd() * 2 * spread;
    const slot = Math.floor(ttl / 10) * 10;
    perWindow.set(slot, (perWindow.get(slot) ?? 0) + 1);
  }
  const slots = [...perWindow.entries()].sort((a, b) => a[0] - b[0]);
  const top = Math.max(...slots.map(([, n]) => n));
  return { windows: slots.length, top, first: slots[0][0], last: slots.at(-1)[0] };
}
for (const j of [0, 5, 10, 20]) {
  const r = peak(j);
  console.log(`jitter +-${String(j).padStart(2)}%  ` +
    `expiry from ${r.first}s to ${r.last + 9}s  ` +
    `peak ${String(r.top).padStart(4)} keys in 10 s  ` +
    `about ${(r.top / 10).toFixed(0)} reloads/s`);
}

৬ · Invalidation: delete, update আর race

বিক্রেতা দাম বদলালেন। ডেটাবেস ঠিক হলো, কিন্তু Redis-এ পুরোনো কপি রয়ে গেল। তিনটি পথ আছে: TTL শেষ হওয়া পর্যন্ত অপেক্ষা, cache-এ নতুন মান লেখা, অথবা key মুছে দেওয়া। সিদ্ধান্তের ভিত্তি পরিষ্কার করতে আসল পরীক্ষা চালানো হলো। Invalidation-এর সাধারণ পছন্দ হলো ডেটাবেসে লেখার পরে DEL.

app.patch('/api/products/:id/price', async (req, res) => {
  const id = Number(req.params.id), price = Number(req.body.price);
  await pool.query(
    'UPDATE products SET price=$1, version=version+1 WHERE id=$2', [price, id]);
  await redis.del(keyOf(id));   // commit-এর পরে, আগে নয়
  res.status(204).end();
});

এখানে যাচাই আর authorization সংক্ষেপের জন্য বাদ, বাস্তবে পর্ব ২৭ আর পর্ব ৪৮-এর মতো লাগবে। কেন SET নয়? দুইজন বিক্রেতা প্রায় একসাথে দাম বদলালে ডেটাবেসে এক ক্রমে আর cache-এ উল্টো ক্রমে লেখা পৌঁছাতে পারে। আর DEL-এ ক্রম গুরুত্বপূর্ণ নয়: যতবারই মুছুন, ফল একই। এ ছাড়া পাতার মান বানাতে পুরো পাতা আবার হিসাব করতে হতো, যা হয়তো কেউ পড়বেনই না।

তবুও একটি race বাকি থাকে

একটি reader cache miss পেয়ে ডেটাবেস থেকে পুরোনো দাম পড়ল। সে Redis-এ লেখার আগেই একজন writer দাম বদলে key মুছল। এবার reader পুরোনো দাম লিখে দিল। এটি একটি race condition. নিচের সময় আসল run থেকে, যেখানে reader-এর পথে ১০০ ms-এর একটি বিরতি ইচ্ছা করে বসানো (যেমন garbage collection-এর থামা)।

1reader: GET → nil2reader: SELECT → 5003reader: (থেমে আছে)4writer: UPDATE → 5205writer: DEL6reader: SET 500 ← পুরোনো7ক্রেতা: GET → 500

“এটি তো কৃত্রিম বিরতি দিয়ে ঘটানো” ভাবছেন? তাই এবার কোনো বিরতি ছাড়াই পরীক্ষা হলো। প্রতি দফায় key মোছা হলো, তারপর ৩টি reader আর ১টি writer একসাথে ছাড়া হলো, আর শেষে cache আর ডেটাবেস মেলানো হলো।

সত্যিকারের run · আসল Redis আর PostgreSQL · একটি local কম্পিউটারে একবার · ইচ্ছা করে race-প্রবণ পরীক্ষা, সাধারণ ট্রাফিকের হার নয়

UPDATE then DEL                      rounds 4000  stale left in cache 139  (3.48%)
DEL then UPDATE (wrong order)        rounds 4000  stale left in cache 2101  (52.52%)
UPDATE then DEL + version guard      rounds 4000  stale left in cache 0  (0.00%)

আগের একটি run-এ একই পরীক্ষায় ১৬১ আর ২১১০ এসেছিল, তাই সংখ্যাগুলো নয়, মাত্রাটি মনে রাখুন। ক্রম উল্টালে প্রায় অর্ধেক দফায় পুরোনো মান থেকে যায়, কারণ মোছা আর commit-এর মাঝে যেকোনো reader পুরোনো দাম এনে বসাতে পারে। দুই writer-এর তুলনাও হলো, যেখানে লেখা আর cache-এর মাঝে ১ থেকে ৫ ms-এর এলোমেলো বিরতি আছে:

সত্যিকারের run · একটি local কম্পিউটারে একবার · ১ থেকে ৫ ms-এর বিরতি ইচ্ছা করে বসানো

two writers, UPDATE then SET   rounds 1000  cache differs from database 378  (37.8%)
two writers, UPDATE then DEL   rounds 1000  cache differs from database 0    (0.0%)

Version guard

পণ্যের সারিতে version কলাম আছে, যা প্রতিটি UPDATE-এ বাড়ে। Writer আলাদা একটি key-তে সবচেয়ে নতুন version লিখে রাখে, আর reader cache-এ লেখার আগে মিলিয়ে দেখে। মিলিয়ে দেখা আর লেখা একসাথে হতে হবে, নইলে আবার race. তাই Lua script, যা Redis-এ অবিচ্ছিন্নভাবে চলে।

// reader: নিজের version পুরোনো হলে cache-এ লিখবে না
const GUARD_SET = `local v = redis.call('GET', KEYS[2])
  if v and tonumber(v) > tonumber(ARGV[2]) then return 0 end
  redis.call('SET', KEYS[1], ARGV[1], 'EX', 300)
  return 1`;

// writer: commit-এর পরে নতুন version লিখে key মোছে
const GUARD_BUMP = `local v = redis.call('GET', KEYS[2])
  if (not v) or tonumber(ARGV[1]) > tonumber(v) then
    redis.call('SET', KEYS[2], ARGV[1], 'EX', 3600)
  end
  redis.call('DEL', KEYS[1])
  return 1`;

await redis.eval(GUARD_SET, { keys: [k, vk], arguments: [json, String(v.version)] });

৪,০০০ দফায় ০ পাওয়া প্রমাণ নয়, কিন্তু যুক্তিটি আলাদা করে খাটে। Reader পুরোনো version নিয়ে দুই অবস্থায় আসতে পারে। Writer version লেখার আগে এলে তার মান writer-এর DEL-এ মুছে যাবে। পরে এলে guard তাকে আটকাবে। তবে এটি একটি বাড়তি জটিলতা। পণ্যের পাতায় ছোট TTL আর UPDATE-এর পরে DEL প্রায়ই যথেষ্ট। যেখানে পুরোনো মানের দাম বড়, সেখানে এই guard ভাবুন, আর সবচেয়ে বড় ক্ষেত্রে cache বাদ দিন। Version key-এর TTL যেন পাতার TTL-এর চেয়ে লম্বা থাকে।

৭ · Cache stampede: lock, single-flight আর stale-while-revalidate

ঈদের অফারের একটি পণ্য। সেকেন্ডে শত শত অনুরোধ, সব hit, ডেটাবেস আরামে। হঠাৎ key-এর TTL শেষ। সেই মুহূর্তে যত অনুরোধ এলো, সবাই miss পেল, আর সবাই একই ভারী query চালাল। একে বলে cache stampede. দোকানের সামনের তাক খালি দেখে সব ক্রেতা একসাথে গুদামে ঢুকে পড়ার মতো।

এবার সত্যিই ঘটানো যাক। দুটি Express instance, প্রতিটিতে ৩০টি একসাথে চলা client, একটি hot key, TTL ২ সেকেন্ড, মোট ৮ সেকেন্ড।

সত্যিকারের run · একটি local কম্পিউটারে একবার · ৮ সেকেন্ডে key ৪ বার ভরা হয়েছে · এটি সাধারণ ফল নয়

৮ সেকেন্ডে ২ সেকেন্ডের TTL মানে ৪ বার ভরা। শুধু cache-aside-এ প্রতিবার ৬০টি client-ই ডেটাবেসে গেছে: ৪ × ৬০ = ২৪০. দরকার ছিল ৪টি। ডেটা ছোট হওয়ায় এই ল্যাব টিকে গেছে, তবু সবচেয়ে ধীর অনুরোধ ৬৯২ ms. সত্যিকারের ভারী query আর ব্যস্ত ডেটাবেসে এই ঢেউ cascading failure শুরু করতে পারে।

Single-flight একটি process-এর ভেতরের সমাধান: একই key-এর জন্য চলতে থাকা কাজ থাকলে নতুন কাজ শুরু না করে সেই Promise-এ অপেক্ষা। Map দিয়ে নকল Redis বানিয়ে ১০০টি অনুরোধে দেখা যাক।

// শেখানোর মডেল: Map-এ নকল Redis, setTimeout-এ ১০ ms-এর নকল ডেটাবেস
const sleep = (ms) => new Promise((r) => setTimeout(r, ms));
function makeApp(useSingleFlight) {
  const cache = new Map(), inflight = new Map();
  const count = { dbReads: 0, maxAtOnce: 0, running: 0 };
  async function loadFromDb(id) {
    count.dbReads++; count.running++;
    count.maxAtOnce = Math.max(count.maxAtOnce, count.running);
    await sleep(10);
    count.running--;
    return { id, price: 320 };
  }
  async function get(id) {
    if (cache.has(id)) return cache.get(id);
    if (!useSingleFlight) {
      const v = await loadFromDb(id); cache.set(id, v); return v;
    }
    let p = inflight.get(id);
    if (!p) {                         // প্রথমজনই শুধু ডেটাবেসে যাবে
      p = loadFromDb(id).then((v) => { cache.set(id, v); return v; })
        .finally(() => inflight.delete(id));
      inflight.set(id, p);
    }
    return p;                         // বাকিরা একই Promise-এ অপেক্ষা করে
  }
  return { get, count };
}
(async () => {
  for (const sf of [false, true]) {
    const app = makeApp(sf);
    const out = await Promise.all(Array.from({ length: 100 }, () => app.get(7)));
    const c = app.count;
    console.log(`single-flight=${String(sf).padEnd(5)} answers=${out.length} dbReads=${c.dbReads} maxAtOnce=${c.maxAtOnce}`);
  }
})();

সব instance-এ একজনকে বাছতে Redis-এই একটি distributed lock রাখা যায়। SET … NX PX একটি আণবিক command: key না থাকলেই বসে, মেয়াদসহ।

1TTL শেষ: key মুছে গেল2A, B, C: GET → nil3A, B, C: SET lock NX4A: ডেটাবেস থেকে আনছে5B, C: 50 ms পরে GET6A: SET key, lock খোলা7B, C: GET → মান

const UNLOCK = `if redis.call('GET',KEYS[1])==ARGV[1]
  then return redis.call('DEL',KEYS[1]) end return 0`;

async function withLock(id) {
  const k = keyOf(id), lk = `lock:${k}`, me = randomUUID();
  const c = await cacheGet(k);
  if (c !== null) return { src: 'HIT', body: JSON.parse(c) };

  let got = null;
  try { got = await redis.set(lk, me, { NX: true, PX: 2000 }); }
  catch { return { src: 'MISS', body: await loadProductPage(id) }; } // Redis নেই

  if (got === 'OK') {
    try {
      const v = await loadProductPage(id);
      if (v) await cacheSet(k, JSON.stringify(v), ttl());
      return { src: 'MISS', body: v };
    } finally {
      await redis.eval(UNLOCK, { keys: [lk], arguments: [me] }).catch(() => {});
    }
  }
  for (let i = 0; i < 40; i++) {            // প্রায় ২ সেকেন্ড, তারপর হাল ছাড়া
    await sleep(50);
    const again = await cacheGet(k);
    if (again !== null) return { src: 'WAIT', body: JSON.parse(again) };
  }
  return { src: 'MISS', body: await loadProductPage(id) };
}

এখানে lock শুধু একটি অপ্টিমাইজেশন। মেয়াদের চেয়ে কাজ বেশি সময় নিলে দুজন একসাথে ডেটাবেসে যেতে পারে, কিন্তু তাতে ক্ষতি শুধু বাড়তি একটি query. তাই এটি ঠিক আছে। টাকা বা স্টকের মতো নিরাপত্তার কাজে এই ধরনের lock-এর ওপর ভরসা করা যায় না (ভাবনার প্রশ্ন ০৪ দেখুন)।

Stale-while-revalidate

অপেক্ষা না করিয়ে পুরোনো মান দিয়ে দিলে কেমন হয়? Stale-while-revalidate-এ মানের ভেতরে একটি নরম মেয়াদ থাকে, আর Redis-এর আসল TTL তার চেয়ে অনেক লম্বা। নরম মেয়াদ পার হলে অনুরোধ সঙ্গে সঙ্গে পুরোনো মান পায়, আর একজনই পেছনে নতুন করে আনে। আমাদের run-এ "STALE":2622 অনুরোধ অপেক্ষা ছাড়াই উত্তর পেয়েছে, ডেটাবেসে refresh হয়েছে মাত্র ৩ বার।

তাহলে ৬৩ কেন? কারণ শুরুতে cache খালি ছিল, কিছুই পুরোনো নেই, তাই ৬০টি client-ই miss করেছে। SWR cold cache-এর stampede ঠেকায় না, শুধু মেয়াদ ফুরানোরটি ঠেকায়। এই পথে দাম কিছুক্ষণ পুরোনো দেখাবে। এটি মেনে নেওয়া যায় কি না, ব্যবসার সিদ্ধান্ত। শুরুর ফাঁক ঢাকতে SWR-এর সাথে lock মেলানো যায়।

Negative caching

কেউ এমন পণ্য চাইলেন, যা নেই। Cache-এ থাকে না, তাই প্রতিবার ডেটাবেস। “নেই” উত্তরটিকেও অল্প সময় জমা রাখলে এই খরচ কমে। আমরা 'null' লিখেছি ৩০ সেকেন্ডের TTL-এ। TTL ছোট রাখুন, কারণ পণ্যটি একটু পরেই তৈরি হতে পারে।

সত্যিকারের run · ৮টি সংযোগ একসাথে · একটি local কম্পিউটারে একবার

negative caching without: same missing id 1000 req -> 1000 page loads, p50 1.15 ms | 1000 different missing ids -> 1000 page loads
negative caching with   : same missing id 1000 req -> 8 page loads, p50 0.72 ms | 1000 different missing ids -> 1000 page loads

একই id-তে ১,০০০ থেকে ৮, আর ৮ হলো সেই ছোট stampede: ৮টি সংযোগই প্রথমে একসাথে miss করেছে। কিন্তু ডানের সংখ্যাটি দেখুন। প্রতিবার আলাদা নেই-এমন id পাঠালে negative caching কোনো কাজেই আসে না, উল্টো Redis-এ আবর্জনা জমে। ইচ্ছাকৃত এমন আক্রমণ ঠেকায় rate limit (API নিরাপত্তা), cache নয়।

৮ · Redis বন্ধ হলে: fail open, আসল run

Cache হলো গতি বাড়ানোর সহায়ক, দোকানের দরজা নয়। হাতের কাছের তাকটি ভেঙে পড়লে দোকান বন্ধ হয় না, দোকানি একটু বেশি হেঁটে গুদাম থেকে আনেন। সফটওয়্যারে এই আচরণের নাম fail open: cache-এর সমস্যা মানে miss, 500 নয়। এই ল্যাবে Redis process সত্যিই বন্ধ করে দেখা হলো। দুটি instance পাশাপাশি চলেছে: একটিতে client-এর ডিফল্ট সেটিং, অন্যটিতে নিচের সেটিং।

const redis = createClient({
  url: process.env.REDIS_URL,
  disableOfflineQueue: true,          // সংযোগ নেই? সঙ্গে সঙ্গে error
  commandOptions: { timeout: 50 },    // শুধু socket-এ না লেখা command-এ খাটে
  socket: {
    connectTimeout: 500,
    reconnectStrategy: (n) => Math.min(n * 100, 2000),
  },
});

function deadline(p, ms = 50) {       // নিজের সময়সীমা
  let t;
  const timer = new Promise((_, rej) => {
    t = setTimeout(() => rej(new Error('cache deadline')), ms);
  });
  return Promise.race([p, timer]).finally(() => clearTimeout(t));
}

async function cacheGet(k) {
  try { return await deadline(redis.get(k)); }
  catch { stat.cacheErr++; return null; }           // error মানে miss
}
async function cacheSet(k, v, ex) {
  try { await deadline(redis.set(k, v, { EX: ex })); }
  catch { stat.cacheErr++; }
}

সত্যিকারের run · node-redis 6.3.1 · ৮টি সংযোগ একসাথে · ভারী পাতা · একটি local কম্পিউটারে একবার

ডিফল্ট client-এ Redis বন্ধ থাকলে প্রতিটি অনুরোধে প্রায় ১০ সেকেন্ড লেগেছে। কারণ দুটি জিনিস মিলে। সংযোগ না থাকলে command offline queue-তে জমে। আর node-redis-এর docs অনুযায়ী commandOptions.timeout-এর ডিফল্ট ৫,০০০ ms. GET-এ ৫ সেকেন্ড আর SET-এ ৫ সেকেন্ড, মোট ১০. উত্তর শেষে 200 ঠিকই এসেছে, কিন্তু ক্রেতা ততক্ষণে চলে গেছেন।

Redis বন্ধ থাকার সময় ৩০০ অনুরোধে cacheErr এসেছে ৬০০ (GET আর SET দুটোই), আর ডেটাবেসে গেছে ৩০০টিই। সব উত্তর 200. এবার দেখা যাক Redis ফিরলে কী হয়।

সত্যিকারের run · Redis আবার চালু, মেমরি খালি · app restart ছাড়াই আবার সংযোগ

Redis back, cache empty
safe first  300 {"200/MISS":132,"200/HIT":168} p50 1.2 ms max 141.2 ms
safe second 300 {"200/HIT":300} p50 1.0 ms max 4.6 ms
safe stats {"db":132,"hit":468,"miss":132,"cacheErr":0,"wait":0,"stale":0}

দুটি জিনিস লক্ষ করুন। এক, app নিজেই আবার সংযোগ করেছে, কেউ restart করেননি। দুই, Redis-এর মেমরি খালি হয়ে গেছে, কারণ আমরা persistence বন্ধ রেখেছিলাম, তাই আবার cold cache. এই ল্যাবে ৫০০টি পণ্যের মধ্যেই অনুরোধ ঘুরেছে, তাই দ্রুত সেরে উঠেছে। বড় সাইটে এই সময় ডেটাবেস পুরো ভার পায়। ধরুন ডেটাবেস সেকেন্ডে ৫০০টি query নিতে পারে, আর ট্রাফিক ২,০০০। Hit rate ৯০% হলে ডেটাবেসে যায় ২০০, স্বস্তি। Redis বন্ধ হলে যায় ২,০০০, মানে চারগুণ ভার। তখন fail open মানে ডেটাবেসও পড়ে যাওয়া। তাই বাস্তবে এর সাথে ডেটাবেসের সংযোগে সীমা, লোড কমানোর পথ বা circuit breaker লাগে। Fail open-এর কাজ দরজা খোলা রাখা, ভিড় সামলানো নয়।

৯ · Memory, eviction আর in-process LRU

Redis মেমরিতে থাকে, আর মেমরি ডিস্কের চেয়ে দামি। প্রতি key-এর সাথে নিজের কিছু খরচ যোগ হয়। এখানে মেপে দেখা হলো:

সত্যিকারের run · Redis 8.10.3 · ১,০০০ byte মানের ১ লাখ key · used_memory-এর পার্থক্য

100000 keys, 1000 byte value, no TTL: 103.5 MiB, 1086 byte/key, MEMORY USAGE 1042
100000 keys, same, with TTL:          106.0 MiB, 1111 byte/key

মানে প্রতি key-এ মানের বাইরে প্রায় ৮৬ byte, আর TTL-এ আরও প্রায় ২৫ byte. হিসাব করা সহজ: আমাদের ১,১৫৫ byte-এর ৫০,০০০টি পাতা × (১,১৫৫ + ১১১) byte ≈ ৬ কোটি ৩৩ লাখ byte, প্রায় ৬০.৪ MiB. আপনার ডেটার আকারে নিজে মেপে নিন, কারণ এই সংখ্যা key-এর নাম আর মানের আকারে বদলায়।

মেমরি শেষ হলে কী হবে, তা ঠিক করে eviction policy. maxmemory 0 আর noeviction Redis-এর ডিফল্ট, মানে কিছু না বদলালে সীমাই নেই। সীমা বসালে আর policy না বদলালে লেখা ব্যর্থ হয়, আসল run-এ এই error:

OOM command not allowed when used memory > 'maxmemory'.

Cache-এর জন্য তাই maxmemory আর allkeys-lru ধরনের policy বসান। একই ৮ MB সীমায় ১ লাখ key লিখলে ৬,৭০৩টি থাকল, ৯৩,২৯৭টি সরল, আর কোনো error নেই। নিচে ১,২০,০০০ অনুরোধের Zipf-ধরনের পরীক্ষা, মূল্যায়ন প্রথম ৪০,০০০ অনুরোধের পরে:

সত্যিকারের run · একটি local কম্পিউটারে একবার · ১,০০০ byte মান · একটি বিশেষ ট্রাফিকের ফল, সব সাইটের নয়

৪ থেকে ৮ MB-তে hit rate ১০ পয়েন্ট বাড়ল, ১৬ থেকে ৩২ MB-তে মাত্র ২.৩. এটিই ট্রাফিকের দীর্ঘ লেজ: শুরুর মেমরি সবচেয়ে কাজে লাগে। ৩২ MB-তে কিছুই সরেনি, তবু ১০০% হয়নি, কারণ প্রথমবার দেখা key অবশ্যই miss. Policy-র তফাত এখানে মেমরির তফাতের চেয়ে কম। Redis-এর LRU নিখুঁত নয়, এটি কয়েকটি key নমুনা নিয়ে আনুমানিক কাজ করে। LFU গণনা রাখে, আর Redis 8.6 থেকে allkeys-lrm-ও আছে, যা শুধু লেখার সময় হিসাব করে। ভেতরের গঠন আছে Eviction আর invalidation পর্বে। JavaScript-এর Map-এ ছোট একটি LRU কিন্তু খুব সহজ:

// শেখানোর মডেল: Map ঢোকানোর ক্রম মনে রাখে, তাই প্রথম key-ই সবচেয়ে পুরোনো
class LRU {
  constructor(max) { this.max = max; this.map = new Map(); }
  get(k) {
    if (!this.map.has(k)) return undefined;
    const v = this.map.get(k);
    this.map.delete(k);          // মুছে আবার ঢোকানো: এখন সে সবচেয়ে নতুন
    this.map.set(k, v);
    return v;
  }
  set(k, v) {
    this.map.delete(k);
    this.map.set(k, v);
    if (this.map.size > this.max) {
      const oldest = this.map.keys().next().value;
      this.map.delete(oldest);
      console.log(`  evict ${oldest}`);
    }
  }
  keys() { return [...this.map.keys()].join(' '); }
}
const c = new LRU(3);
for (const [op, k] of [['set', 'A'], ['set', 'B'], ['set', 'C'], ['get', 'A'],
                       ['set', 'D'], ['get', 'B'], ['set', 'E']]) {
  const r = op === 'get' ? c.get(k) : c.set(k, k.toLowerCase());
  const note = op === 'get' ? (r === undefined ? ' -> miss' : ' -> hit') : '';
  console.log(`${op} ${k}${note}   [পুরোনো → নতুন] ${c.keys()}`);
}

In-process LRU বনাম Redis, কয়েকটি instance-এ

Process-এর ভেতরের LRU দ্রুত, Redis লাগে না। তাহলে Redis কেন? দুটি instance চালিয়ে A-তে দাম ৭০০ থেকে ৭৫০ করা হলো।

সত্যিকারের run · দুটি Express instance · TTL ৬০ সেকেন্ড · lru মানে process-এর ভেতরের cache, aside মানে Redis · একটি local কম্পিউটারে একবার · উত্তর ছাঁটা

--- lru
PATCH price 750 through A
A 200 MISS price 750
B 200 HIT price 700
A {"HIT":4000}: p50 0.141 ms p99 0.538 ms

--- aside
PATCH price 750 through A
A 200 MISS price 750
B 200 HIT price 750
A {"HIT":4000}: p50 0.346 ms p99 0.802 ms

In-process cache-এ B পুরোনো দাম দেখাল, আর TTL শেষ না হওয়া পর্যন্ত দেখাবে, কারণ A-র মোছা B জানে না। Redis-এ সবাই একই কপি দেখে। আর দাম হলো প্রতি hit-এ network-এর একটি যাওয়া-আসা, এখানে HTTP-সহ মোট ০.১৪১ বনাম ০.৩৪৬ ms. In-process cache-এর প্রতিটি instance-এ নিজের কপি থাকে, restart-এ হারায়, আর Node.js-এর heap-এ চাপ দেয়।

একটি server হলে in-process LRU প্রায়ই যথেষ্ট। বড় সিস্টেমে দুটি মিলিয়ে দুই স্তরের cache হয়, যা Distributed cache পর্বে আছে।

১০ · AI-এর যুগে: cache-এর কোড যাচাই

AI সহজেই একটি “কাজ করা” cache লিখে দেয়। Demo-তে সব ঠিক থাকে, কারণ এই পর্বের ভুলগুলো ধরা পড়ে শুধু একসাথে অনেক অনুরোধে, লেখার সময়ে, বা Redis বন্ধ হলে। সাধারণ ভুলগুলো:

AI-এর লেখা cache হাতে পেলে

• Cache ছাড়া আর cache-সহ মেপেছি, আর সমতার বিন্দু হিসাব করেছি
• প্রতিটি key-তে TTL আছে, TTL command চালিয়ে দেখেছি
• দুই আলাদা user দিয়ে চালিয়ে দেখেছি, একজনের ডেটা অন্যজন পাচ্ছেন না
• Update-এর পরপরই পড়ে নতুন মান পেয়েছি
• Redis সত্যিই বন্ধ করে আর CLIENT PAUSE দিয়ে চালিয়েছি, উত্তর সময়মতো এসেছে
• একই key-তে একসাথে অনেক অনুরোধ পাঠিয়ে ডেটাবেসের query গুনেছি
• প্রতিটি option নিজের version-এর docs-এ পেয়েছি