Caching — tezlikning birinchi quroli

Bosh sahifangizdagi "eng ko‘p sotilganlar" ro‘yxatini olaylik. Unga sekundiga 5000 odam kiradi va har biri uchun baza bir xil og‘ir JOINli so‘rovni qayta-qayta bajaradi.

Keshning ikki holati bor va butun mavzu shu ikkitasi atrofida aylanadi:

• Cache HIT — so‘ralgan ma’lumot keshda bor → darhol qaytariladi (bazaga bormaydi).
• Cache MISS — keshda yo‘q → bazadan olinadi, keshga yoziladi, qaytariladi.

Keshning samarasi hit rate (necha % so‘rov keshdan javob oldi) bilan o‘lchanadi. 90% hit rate = bazaga atigi 10% so‘rov tushadi.

Kesh qayerda yashaydi — bir necha qatlam

Kesh bitta joy emas — foydalanuvchidan bazagacha bir necha bosqichda bo‘lishi mumkin. Har biri bazaga yetib borishni kamaytiradi:

Kesh va baza qanday muvofiqlashadi — bir necha naqsh bor. Eng muhim 4 tasi:

1 · Cache-Aside (lazy loading) — eng keng tarqalgan

Ilova keshni o‘zi boshqaradi: avval keshdan so‘raydi, miss bo‘lsa bazadan olib, keshga yozadi. Kesh "yon"da turadi (aside).

Yozish strategiyalari — Write-through va Write-behind

NestJS keshni @nestjs/cache-manager orqali beradi. Ikki usul bor: avtomatik (interceptor) va qo‘lda (to‘liq nazorat). Production’da odatda qo‘lda Cache-Aside ko‘proq ishlatiladi.

1 · Kesh modulini ulash (Redis)

// app.module.ts — Redis bilan kesh modulini ulaymiz
import { CacheModule } from '@nestjs/cache-manager';
import { redisStore } from 'cache-manager-redis-yet';

@Module({
  imports: [
    CacheModule.registerAsync({
      isGlobal: true,
      useFactory: async () => ({
        store: await redisStore({ url: 'redis://localhost:6379' }),
        ttl: 60_000,   // DIQQAT: cache-manager v5 da TTL = millisekund
      }),
    }),
  ],
})
export class AppModule {}

2 · Qo‘lda Cache-Aside — to‘liq nazorat

// product.service.ts — qo'lda Cache-Aside (eng ko'p ishlatiladigan naqsh)
import { CACHE_MANAGER } from '@nestjs/cache-manager';
import { Cache } from 'cache-manager';

@Injectable()
export class ProductService {
  constructor(
    @Inject(CACHE_MANAGER) private cache: Cache,
    private repo: ProductRepository,
  ) {}

  async getById(id: string): Promise<Product> {
    const key = `product:${id}`;
    const cached = await this.cache.get<Product>(key);
    if (cached) return cached;                       // HIT -> darhol

    const product = await this.repo.findById(id);    // MISS -> bazadan
    await this.cache.set(key, product, 60_000);      // keshga yoz (60s)
    return product;
  }

  async update(id: string, dto: UpdateProductDto) {
    const product = await this.repo.update(id, dto);
    await this.cache.del(`product:${id}`);           // INVALIDATE (eskisini o'chir)
    return product;
  }
}

3 · Avtomatik keshlash — interceptor

Oddiy, kam o‘zgaradigan GET endpointlar uchun qulay — kod yozmasdan keshlaydi:

// Avtomatik HTTP keshlash — interceptor (oddiy GET endpointlar uchun)
import { CacheInterceptor, CacheKey, CacheTTL } from '@nestjs/cache-manager';

@Controller('products')
@UseInterceptors(CacheInterceptor)
export class ProductController {
  @Get()
  @CacheKey('products_all')
  @CacheTTL(30_000)          // 30s
  findAll() { return this.service.findAll(); }
}

3 ta yondashuv

1 · TTL (Time To Live) — eng oddiy. Har keshga yashash muddati beriladi (masalan 60s). Muddat tugagach o‘zi o‘chadi va keyingi so‘rovda yangilanadi. Kelishuv: TTL davomida ma’lumot biroz eskirgan bo‘lishi mumkin. Ko‘p hollarda — joiz.

2 · Yozuvda invalidatsiya (write invalidation). Ma’lumot o‘zgarganda keshdagi kalitni darhol del qilasan (yuqoridagi update misolidagidek). Eng aniq, lekin har o‘zgarish joyida keshni o‘chirishni eslab turish kerak.

3 · Hodisaga asoslangan invalidatsiya. O‘zgarishda event chiqadi, keshga bog‘liq joylar o‘zini tozalaydi — bo‘shroq bog‘langan:

// Hodisaga asoslangan invalidatsiya (3-mavzu bilan bog'lanadi)
// Mahsulot o'zgarganda event chiqadi -> keshlar o'zini tozalaydi
@OnEvent('product.updated')
async onProductUpdated(e: ProductUpdated) {
  await this.cache.del(`product:${e.id}`);
  await this.cache.del('products_all');     // bog'liq ro'yxat keshini ham
}

Keshda 3 ta klassik muammo bor — ularni bilmaslik tizimni yiqitishi mumkin:

1 · Cache Stampede (thundering herd)

Mashhur kalit keshdan o‘chdi (TTL tugadi). Ayni o‘sha lahzada minglab so‘rov birato‘la miss bo‘lib, hammasi bazaga yuguradi — baza to‘fondan cho‘kadi.

Yechim (qisqacha): faqat bitta so‘rov bazaga borib keshni to‘ldirsin (lock / "single-flight"), qolganlar kutsin; yoki muddat tugashidan oldin fonda yangilash. (Chuqur mexanika — Deep qatlamda.)

2 · Cache Avalanche (qor ko‘chkisi)

Ko‘p kalitga bir xil TTL berilgan → hammasi bir vaqtda tugaydi → bir zumda ulkan miss to‘lqini. Yechim: TTL’ga tasodifiy qo‘shimcha (jitter) ber: 60s + random(0..10s) — muddatlar tarqaladi.

3 · Cache Penetration (teshib o‘tish)

So‘rovlar umuman mavjud bo‘lmagan kalitga tushadi (masalan, product:-1). Kesh doim miss, har safar baza benihoya so‘raladi (hatto buzg‘unchi shu orqali bazani yuklashi mumkin). Yechim: "yo‘q" natijani ham qisqa TTL bilan keshla (negative caching).

Eviction — kesh to‘lganda nima o‘chadi

Kesh xotirasi cheksiz emas. To‘lganda eskilarini chiqarib tashlaydi (eviction). Asosiy siyosatlar: LRU (eng kam yaqinda ishlatilgani), LFU (eng kam tez-tez ishlatilgani), TTL (muddati bo‘yicha). Redis’da bu maxmemory-policy bilan sozlanadi.

Kesh kuchli, lekin har joyda emas. Noto‘g‘ri ishlatilsa — eskirgan ma’lumot va topish qiyin xatolar keltiradi.

• Kesh = tez-tez o‘qiladigan ma’lumotni tez xotirada saqlash. HIT (~1ms) bazaga bormaydi; MISS bazadan olib keshga yozadi.
• Eng ko‘p ishlatiladigan naqsh — Cache-Aside + TTL. Shundan boshla; write-through/behind keyin kerak bo‘lsa.
• Invalidatsiya — eng qiyin qism. TTL (oddiy), yozuvda del (aniq), yoki hodisaga asoslangan. Tezlik va izchillik orasidagi kelishuv.
• 3 ta tuzoq: stampede (lock/single-flight), avalanche (TTL jitter), penetration (negative caching). Kesh to‘lsa — LRU/LFU eviction.
• Faqat ko‘p o‘qiladigan, kam o‘zgaradigan, eskirishi joiz ma’lumotni keshla. O‘lchab keshla, hit rate kuzat, keshga majburiy tayanma.