Caching — Senior chuqurlik

Yechim 1 · Lock / mutex (eng aniq)

Faqat bitta so‘rov qulfni egallab bazaga boradi va keshni to‘ldiradi; qolganlar qisqa kutib, keshdan oladi. Redis SET NX PX bilan taqsimlangan qulf:

// STAMPEDE himoyasi: faqat BITTA so'rov bazaga boradi, qolganlar kutadi
const RELEASE = `if redis.call("get",KEYS[1])==ARGV[1]
                 then return redis.call("del",KEYS[1]) else return 0 end`;

async getWithLock<T>(key: string, ttlMs: number, loader: () => Promise<T>): Promise<T> {
  const hit = await this.redis.get(key);
  if (hit) return JSON.parse(hit);                          // HIT

  const lockKey = `lock:${key}`, token = randomUUID();
  // SET ... NX = faqat qulf bo'sh bo'lsa egalla (atomik)
  const locked = await this.redis.set(lockKey, token, 'PX', 5000, 'NX');
  if (!locked) {                                            // boshqa so'rov tiklamoqda
    await sleep(50);
    return this.getWithLock(key, ttlMs, loader);            // kutib qayta urin
  }
  try {
    const value = await loader();                           // FAQAT shu so'rov DB'ga
    await this.redis.set(key, JSON.stringify(value), 'PX', ttlMs);
    return value;
  } finally {
    await this.redis.eval(RELEASE, 1, lockKey, token);      // qulfni atomik bo'shat
  }
}

Yechim 2 · Probabilistic early expiration (eng silliq)

Lock’siz yondashuv: qiymat muddat tugashidan oldin, ehtimollik bilan bitta so‘rov tomonidan fonda yangilanadi. Shunday qilib hech qachon "hamma birdan miss" holati bo‘lmaydi:

// PROBABILISTIC EARLY EXPIRATION (XFetch): muddat tugashidan OLDIN, ehtimollik
// bilan bitta so'rov fonda qayta hisoblaydi -> hammasi bir vaqtda miss bo'lmaydi.
function shouldRecompute(delta: number, expiry: number, beta = 1.0): boolean {
  // delta = qiymatni hisoblash qancha vaqt olgani (ms)
  return Date.now() - delta * beta * Math.log(Math.random()) >= expiry;
}
// HIT bo'lsa ham shouldRecompute() true qaytarsa -> fonda yangilaymiz (stale-while-revalidate)

Yechim 3 · Stale-while-revalidate

Muddat tugasa ham, eski qiymatni darhol qaytaramiz (foydalanuvchi kutmaydi), fonda esa yangisini hisoblab keshni yangilaymiz. Tezlik birinchi, izchillik biroz keyin.

// CACHE-ASIDE NING MASHHUR RACE'i (Facebook "scaling memcache" muammosi)
//
// T1 (o'qish): miss -> bazadan ESKI qiymat o'qidi (X=1), hali keshga yozmadi
// T2 (yozish): bazaga YANGI yozdi (X=2) -> cache.del(key) qildi
// T1: endi cache.set(key, X=1) qiladi -> KESH ESKI QIYMATDA QOLDI (stale, abadiy!)
//
// Yechimlar (kuchayuvchi tartibda):
// 1) Qisqa TTL  -> stale faqat TTL davomida (eng oddiy "xavfsizlik to'ri")
// 2) Write-through -> yozuvda keshni del emas, YANGISINI yoz
// 3) Versiya/CAS -> keshga versiya bilan yoz; eski versiyani yozishni RAD et
// 4) Lease (memcache) -> miss'da "lease token" beriladi; faqat shu token to'ldira oladi

Versiya/CAS bilan to‘g‘ri yechim

Eng ishonchli — har yozuvga versiya berib, keshga faqat yangiroq versiyani yozish (eski kelib qolsa — rad etish). Atomiklik uchun Redis Lua:

// VERSIYA bilan himoya: har yozuvda version oshadi; eski versiyani yozma
async setIfNewer(key: string, value: any, version: number) {
  const LUA = `
    local cur = redis.call("HGET", KEYS[1], "v")
    if cur and tonumber(cur) >= tonumber(ARGV[2]) then return 0 end
    redis.call("HSET", KEYS[1], "v", ARGV[2], "data", ARGV[1])
    return 1`;
  return this.redis.eval(LUA, 1, key, JSON.stringify(value), version);
}

L1 (lokal) + L2 (Redis)

L1 — server jarayoni ichida (eng tez, lekin kichik va har nusxada alohida). L2 — Redis (umumiy, izchil). So‘rov avval L1, keyin L2, keyin manbaga:

// L1 = lokal (in-memory LRU, ~ns) + L2 = Redis (umumiy, ~1ms)
async get<T>(key: string, loader: () => Promise<T>): Promise<T> {
  const l1 = this.local.get(key);            // L1
  if (l1 !== undefined) return l1;           // eng tez

  const l2 = await this.redis.get(key);      // L2
  if (l2) { const v = JSON.parse(l2); this.local.set(key, v); return v; }

  const v = await loader();                  // MISS -> manba
  await this.redis.set(key, JSON.stringify(v), 'PX', 60_000);
  this.local.set(key, v);
  return v;
}

// L1 muammosi: har server nusxasida ALOHIDA L1. Biri yangilansa, boshqalarda eski.
// Yechim: Redis pub/sub orqali HAMMA nusxaga "bu kalitni L1'dan o'chir" signali.
async invalidate(key: string) {
  await this.redis.del(key);                       // L2
  await this.redis.publish('cache:evict', key);    // hamma nusxaga e'lon
}
// har nusxa ishga tushganda:
this.sub.subscribe('cache:evict');
this.sub.on('message', (_ch, key) => this.local.del(key));   // lokal L1'ni tozala

1 · Single-threaded — eng muhim fakt

Redis buyruqlarni bitta oqimda, ketma-ket bajaradi. Demak O(N) buyruq (masalan KEYS *, katta SMEMBERS) butun Redis’ni bloklaydi — boshqa hamma so‘rov kutadi. Shuning uchun productionda hech qachon KEYS ishlatmaysan, SCAN ishlatasan:

// ❌ YOMON: KEYS butun Redis'ni BLOKLAYDI (single-thread!) - productionda halokat
// const keys = await redis.keys('product:*');

// ✅ YAXSHI: SCAN kursor bilan, bloklamasdan bo'lib-bo'lib
let cursor = '0';
do {
  const [next, batch] = await redis.scan(cursor, 'MATCH', 'product:*', 'COUNT', 100);
  cursor = next;
  for (const k of batch) { /* ... */ }
} while (cursor !== '0');

2 · To‘g‘ri ma’lumot strukturasini tanlash

Redis — shunchaki "key-value" emas. To‘g‘ri struktura xotira va tezlikni keskin o‘zgartiradi:

3 · Persistence va eviction — kesh rejimi

Toza kesh uchun Redis’da persistence (RDB/AOF) ko‘pincha o‘chiriladi (tezroq), eviction esa yoqiladi:

# redis.conf — Redis'ni KESH sifatida ishlatish (durable store emas)
maxmemory 2gb
maxmemory-policy allkeys-lru   # to'lganda eng kam ishlatilganni chiqar
# eviction siyosatlari: noeviction | allkeys-lru | allkeys-lfu
#                       volatile-lru | volatile-ttl | allkeys-random
save ""          # RDB snapshot OFF (kesh uchun kerak emas)
appendonly no    # AOF OFF -> tezroq, lekin restartda kesh bo'sh (normal)

Sharding va consistent hashing

Kalitlarni tugunlarga taqsimlashning sodda yo‘li — hash(key) % N. Lekin tugun qo‘shilsa/o‘chsa, N o‘zgaradi va deyarli hamma kalit boshqa tugunga ko‘chadi (ommaviy miss). Consistent hashing buni hal qiladi: tugun o‘zgarganda faqat kichik qismi ko‘chadi.

Redis Cluster buni 16384 ta hash slot orqali qiladi: har kalit CRC16(key) % 16384 bo‘yicha slotga, slotlar esa tugunlarga taqsimlanadi. Ishonchlilik uchun har tugunning replikasi + avtomatik failover bo‘ladi.

Senior darajada ishlatiladigan qo‘shimcha naqshlar:

1 · Cache warming (sovuq keshni isitish)

Deploy yoki Redis restartdan keyin kesh bo‘sh bo‘ladi — birinchi foydalanuvchilar to‘lqini bazani uradi (stampede’ning bir ko‘rinishi). Yechim: eng muhim kalitlarni oldindan to‘ldirish:

// CACHE WARMING: deploy yoki restart'dan keyin "sovuq kesh" muammosi.
// Eng muhim kalitlarni oldindan to'ldiramiz (foydalanuvchidan oldin).
@Cron('0 */6 * * *')               // har 6 soatda
async warmTopProducts() {
  const top = await this.repo.findTop(100);    // eng mashhur 100 mahsulot
  await Promise.all(top.map((p) =>
    this.redis.set(`product:${p.id}`, JSON.stringify(p), 'PX', 3_600_000),
  ));
}

2 · Bloom filter — penetration’ning yetuk yechimi

Core’da "negative caching" ko‘rdik. Undan yetukroq — Bloom filter: mavjud bo‘lmagan kalitni Redis’ga ham bormasdan rad etish (juda kam xotira):

// PENETRATION'ga qarshi Bloom filter: "bu ID umuman bormi?" ni Redis'ga
// bormasdan, juda tez va kam xotira bilan tekshiradi (RedisBloom moduli)
await redis.call('BF.ADD', 'products:exist', productId);   // mavjudlarni qo'shamiz
const maybe = await redis.call('BF.EXISTS', 'products:exist', wantedId);
if (maybe === 0) return null;   // ANIQ yo'q -> bazaga ham, keshga ham bormaymiz
// (Bloom filter "yo'q" desa 100% yo'q; "bor" desa ehtimol bor -> keyin tekshiriladi)

3 · TTL strategiyasi — sliding vs absolute

Absolute TTL: yozilgandan N vaqt o‘tib o‘chadi (har doim yangilanadi). Sliding TTL: har o‘qishda muddat uzayadi (mashhur kalitlar uzoq yashaydi, sessiyalar uchun ideal). Ma’lumot turiga qarab har xil TTL tanlash — senior odat.

Kuzatiladigan metrikalar

Diagnostika vositalari

INFO stats — hit/miss, eviction; SLOWLOG — sekin buyruqlar; --bigkeys — katta kalitlar; --hotkeys — issiq kalitlar; MEMORY USAGE key — kalit hajmi. MONITOR esa productionda ehtiyotkorlik bilan (har buyruqni ko‘rsatadi, sekinlashtiradi).

Lab’ning yadrosi va senior tekshiruvi.

1 · Infratuzilma

# docker-compose.yml — lab uchun Redis
services:
  redis:
    image: redis:7-alpine
    command: redis-server --maxmemory 256mb --maxmemory-policy allkeys-lru
    ports: ["6379:6379"]

2 · Eng muhim test — stampede himoyasi concurrency ostida

Senior belgisi: keshni nafaqat "hit/miss" balki parallel yuk ostida testlash. Quyidagi test lock chinakam ishlashini isbotlaydi:

// Testlar: hit/miss, invalidatsiya VA stampede himoyasini concurrency bilan
it('100 ta parallel miss -> bazaga FAQAT 1 marta boradi', async () => {
  const loader = jest.fn().mockResolvedValue({ id: '1', price: 100 });
  // 100 ta so'rovni BIR VAQTDA yuboramiz (sovuq kesh)
  await Promise.all(
    Array.from({ length: 100 }, () => cache.getWithLock('product:1', 60_000, loader)),
  );
  expect(loader).toHaveBeenCalledTimes(1);   // lock ishladi -> bazaga 1 marta!
});

3 · Senior tayyorlik cheklisti

Hammasiga "ha" desang — keshlash bo‘yicha senior darajadasan: