Redis-bufring og meldinger (Pub/Sub, Streams) · leksjon

Implementere grunnleggende cachemønstre

Lær å implementere mønstrene Cache-Aside og Write-Through med Redis for vanlige applikasjonsdata.

Leksjon 2 av 411 trinn

Implementere grunnleggende cachemønstre er en gratis leksjon i Redis-bufring og meldinger (Pub/Sub, Streams) på CoddyKit. Dette er leksjon 2 av 4. Du kan lese valgfritt 3 leksjoner fra denne læringsstien gratis i sin helhet – deretter låser CoddyKit PRO opp alle leksjoner, samt praktisk øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Redis-bufring og meldinger (Pub/Sub, Streams), og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Redis-bufring og meldinger (Pub/Sub, Streams) inneholder totalt 4 leksjoner.

Introduksjon til grunnleggende hurtigbuffermønstre

Velkommen! I denne leksjonen skal vi se nærmere på to grunnleggende mønstre for hurtigbufring: Cache-Aside og Write-Through. Disse mønstrene hjelper deg med å integrere Redis i appene dine, slik at data kan lagres og hentes effektivt.

Å forstå dem er viktig for å bygge responsive og skalerbare systemer.

Hva er Cache-Aside?

Cache-Aside-mønsteret er en av de vanligste måtene å bruke en hurtigbuffer på. Her har appen ansvaret for å håndtere både hurtigbufferen og det primære datalageret (for eksempel en database).

  • Ved lesing av data kontrollerer appen hurtigbufferen først.
  • Hvis dataene finnes der (et «cache hit»), returnerer appen de hurtigbufrede dataene.
  • Hvis de ikke finnes (et «cache miss»), henter appen dataene fra databasen, lagrer dem i hurtigbufferen og returnerer dem deretter.

Cache-Aside: Lese flyten

Tenk deg at appen trenger brukerdata. Slik fungerer Cache-Aside:

  1. Appen ber om data: Kontrollerer Redis for user:123.
  2. Cache Miss: Redis svarer «ikke funnet».
  3. Appen spør databasen: Henter user:123 fra databasen.
  4. Appen oppdaterer hurtigbufferen: Lagrer user:123 i Redis.
  5. Appen returnerer dataene: Leverer dataene til brukeren.
  6. Senere forespørsler: Nå har Redis user:123, noe som gir et raskt «cache hit»!

Cache-Aside: CLI-eksempel

La oss simulere en Cache-Aside-leseflyt med Redis CLI. Først prøver vi å hente en nøkkel som ikke ligger i hurtigbufferen (miss). Deretter henter vi den fra en tenkt database og lagrer den. Til slutt henter vi den på nytt (hit).

DEL product:101
GET product:101

# Simulate fetching from DB: "Laptop X"
SET product:101 "Laptop X" EX 3600

GET product:101

Cache-Aside: Fordeler og ulemper

Fordeler:

  • Enkelhet: Enkel å implementere.
  • Lesetunge arbeidsbelastninger: Utmerket for data som leses ofte, men endres sjelden.
  • Dataenes aktualitet: Nye data legges bare til i cachen når de etterspørres, noe som reduserer forurensning av cachen.

Ulemper:

  • Innledende forsinkelse: Den første lesingen av data fører alltid til en cache-miss, noe som gjør den tregere.
  • Utdaterte data: Hvis databasen oppdateres direkte, kan cachen inneholde gamle data til de utløper eller eksplisitt ugyldiggjøres.

Hva er Write-Through?

Mønsteret Write-Through sørger for at data skrives til både cachen og det primære datalageret (databasen) samtidig. Applikasjonen skriver til cachen, og cachen har ansvaret for å skrive dataene til databasen.

  • Når data skrives, går de først til cachen.
  • Cachen skriver deretter dataene umiddelbart til databasen.
  • Skriveoperasjonen regnes som fullført først når begge operasjonene er vellykkede.

Write-Through: Skriveflyten

Se for deg at prisen på et produkt skal oppdateres. Slik fungerer Write-Through:

  1. Applikasjonen skriver data: Sender den nye produktprisen for product:202 til Redis.
  2. Cachen skriver til databasen: Redis skriver umiddelbart den samme oppdateringen til databasen.
  3. Cachen bekrefter: Redis bekrefter skrivingen overfor applikasjonen først når skrivingen til databasen er fullført.
  4. Applikasjonen fortsetter: Applikasjonen går videre, vel vitende om at både cachen og databasen er konsistente.

Write-Through: CLI-eksempel

Med Write-Through utfører applikasjonen vanligvis én enkelt skriveoperasjon til cachen, mens cachen (eller et klientbibliotek som implementerer mønsteret) håndterer lagringen i databasen. Her simulerer vi innstillingen av en verdi som i praksis også ville oppdatert databasen.

SET user:456 '{"name": "Alice", "email": "alice@example.com"}'

# Conceptually, this SET command
# would trigger an update to your
# primary database as well.

GET user:456

Write-Through: Fordeler og ulemper

Fordeler:

  • Datakonsistens: Cachen og databasen er alltid synkronisert.
  • Pålitelighet: Data lagres umiddelbart permanent.
  • Enklere lesing: Alle lesinger treffer cachen (forutsatt at data alltid skrives med Write-Through).

Ulemper:

  • Skriveforsinkelse: Skrivingen går tregere fordi data må skrives to ganger (cache + database).
  • Forurensning av cachen: Data som skrives til cachen, blir kanskje aldri lest, slik at cache-plass sløses bort.
  • Økt belastning: Hver skriveoperasjon medfører en skriving til databasen, noe som potensielt øker belastningen på databasen.

Quiz: Sammenligning av mønstre

Du utformer en funksjon der brukerprofiler leses ofte, men oppdateres sjeldnere. Hvilket cache-mønster vil vanligvis være best egnet for å optimalisere lese ytelsen og forenkle implementeringen?

Oppsummering: Grunnleggende cache-mønstre

Godt jobbet! Du har lært om to grunnleggende strategier for caching:

  • Cache-Aside: Applikasjonen administrerer cachen. Ved lesing sjekkes cachen først. Ved cache-miss hentes data fra databasen, legges i cachen og returneres deretter. Best for lesetunge data.
  • Write-Through: Skrivinger går til cachen, som deretter umiddelbart skriver til databasen. Sikrer sterk konsistens mellom cachen og databasen.

Disse mønstrene danner grunnlaget for mer avanserte cache-teknikker som du skal utforske i fremtidige leksjoner!

Gratis å komme i gang

Lær deg Redis-bufring og meldinger (Pub/Sub, Streams) med en AI-veileder – gratis

Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.

Kurs
12
Leksjoner
48

Ofte stilte spørsmål

Er leksjonen «Implementere grunnleggende cachemønstre» gratis?

Ja – du kan lese valgfritt 3 av leksjonene i læringsstien Redis-bufring og meldinger (Pub/Sub, Streams), inkludert «Implementere grunnleggende cachemønstre», gratis i sin helhet her på nettet. Deretter låser CoddyKit PRO opp alle leksjoner, samt interaktiv øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Kurset i Redis-bufring og meldinger (Pub/Sub, Streams) inneholder totalt 4 leksjoner.

Hva lærer jeg i «Implementere grunnleggende cachemønstre»?

Lær å implementere mønstrene Cache-Aside og Write-Through med Redis for vanlige applikasjonsdata. Du øver på Redis-bufring og meldinger (Pub/Sub, Streams) med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.

Trenger jeg erfaring for å begynne med Redis-bufring og meldinger (Pub/Sub, Streams)?

Ingen tidligere erfaring er nødvendig. Redis-bufring og meldinger (Pub/Sub, Streams) på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 2 av 4.

Hvor lang tid tar leksjonen «Implementere grunnleggende cachemønstre»?

De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.

Kan jeg skrive og kjøre kode i denne Redis-bufring og meldinger (Pub/Sub, Streams)-leksjonen?

Ja. Alle Redis-bufring og meldinger (Pub/Sub, Streams)-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.

Alle leksjonene i dette kurset

  1. Hvorfor cache? Introduksjon til caching
  2. Implementere grunnleggende cachemønstre
  3. Utkasting og utløp av cache
  4. Forebygging av cache-stampeder og «thundering herd»
← Tilbake til Redis-bufring og meldinger (Pub/Sub, Streams)