Kokie gadinimo strategijos pagerina Node API veikimą?

Question

Accepted Answer

**Gadinimas (caching)** saugo brangių operacijų rezultatus (DB užklausas, skaičiavimus, išorinius API skambučius), kad pakartotiniai prašymai galėtų būti patenkinti greitai nepakartojant darbo. Tai vienas iš didžiausio poveikio API veikimo optimizavimo metodų.

## Atmintyje atliekamas gadinimas (greičiausias, viena instancija)

```js
const cache = new Map();

async function getUser(id) {
  if (cache.has(id)) return cache.get(id); // cache HIT — instant
  const user = await db.findUser(id);       // cache MISS — do the work
  cache.set(id, user);
  return user;
}
```

Paprastas ir itin greitas, tačiau gadinimo saugykla yra **pagal procesą** (nedalinta tarp instancijų) ir prarandama iš naujo paleidus. Tinka mažiems, karštiems duomenims — tačiau reikia šalinimo (naudokite LRU gadinimą kaip `lru-cache`), kad ribotumėte atmintį.

## Paskirstytasis gadinimas su Redis (dalinta, skalandi)

```js
import { createClient } from "redis";
const redis = createClient();

async function getUser(id) {
  const cached = await redis.get(`user:${id}`);
  if (cached) return JSON.parse(cached);          // hit

const user = await db.findUser(id);
  await redis.setEx(`user:${id}`, 3600, JSON.stringify(user)); // cache for 1h (TTL)
  return user;
}
```

**Redis** yra standartas gadinimui keliose serverio instancijose — dalinta, greita saugykla, kuri išgyvena paleidimus iš naujo ir skalindama su jūsų programa. **TTL** (galiojimo trukmė) automatiškai nuslepia įrašus, kad duomenys nesenų išnaš amžiną.

## HTTP gadinimas (leiskite klientams/CDN gaminti)

```js
res.set("Cache-Control", "public, max-age=3600"); // browsers/CDN cache for 1h
res.set("ETag", hash);                            // conditional requests (304 Not Modified)
```

HTTP gadinimo antraštės iškelią gadinimą į naršykles ir CDN visiškai — greičiausias gadinimas yra užklausa, kuri niekada nepasiekia jūsų serverio.

## Sudėtinga dalis: gadinimo negaliojimas

```js
// when data changes, the cache must be updated or cleared, or users see stale data
async function updateUser(id, data) {
  await db.updateUser(id, data);
  await redis.del(`user:${id}`); // INVALIDATE — next read repopulates with fresh data
}
```

Didžiausias gadinimo iššūkis yra **negaliojimas** — užtikrinti, kad atnaujinimai išvalytų/atnaujintų paveiktus gadinimo įrašus, kad vartotojai nematytų pasenusių duomenų. Strategijos: TTL (priimkite trumpą pasenumą), write-through (atnaujinkite gadinimą rašant) arba aiškus naikinimas mutavimo metu.

## Ką gadininti (ir negardininti)

```text
✓ Read-heavy, infrequently-changing data (config, product catalogs, user profiles)
✓ Expensive computations, external API responses
✗ Highly dynamic/personalized or rapidly-changing data (or use very short TTLs)
✗ Sensitive data without care for who can read the cache
```

## Kodėl tai svarbu

Gadinimas dramatiškai sumažina latencija ir duomenų bazės/išorinę apkrovą, dažnai tai yra skirtumas tarp lėto API ir greito, skaliuojamo.

Žinant sluoksnius — atmintyje (greičiausias, pagal instancija, ribojamas su LRU), Redis (dalinta tarp instancijų) ir HTTP/CDN gadinimas (visiškai iškelti) — galite pasirinkti tinkamą strategiją.

Ir supratimas gadinimo centrinės sunkios vietos, **negaliojimo** (per TTL arba aiškų išvalymą rašant), yra tai, kas neleidžia klasikiniam kompromiso nepavykimui — vartotojams pateikti pasenusių duomenų.

Efektyvus gadinimas yra vienas iš labiausiai paplitusių API veikimo ir mastelkabilumo įrankių.