Implementering af grundlæggende cachemønstre

Forestil dig, at din app har brug for brugerdata. Sådan fungerer Cache-Aside:

1. Appen anmoder om data: Kontrollerer Redis for user:123.
2. Cache-miss: Redis svarer »ikke fundet«.
3. Appen forespørger databasen: Henter user:123 fra databasen.
4. Appen opdaterer cachen: Gemmer user:123 i Redis.
5. Appen returnerer data: Leverer dataene til brugeren.
6. Efterfølgende forespørgsler: Nu har Redis user:123, hvilket giver et hurtigt »cache hit«!

Lad os simulere et Cache-Aside-læseforløb ved hjælp af Redis CLI. Først prøver vi at hente en nøgle, der ikke findes i cachen (miss), derefter henter vi den fra en tænkt database og gemmer den. Til sidst henter vi den igen (hit).

Fordele:

• Enkelhed: Nem at implementere.
• Læsetunge arbejdsbelastninger: Fremragende til data, der læses ofte, men sjældent ændres.
• Dataaktualitet: Nye data føjes kun til cachen, når de efterspørges, hvilket reducerer cacheforurening.

Ulemper:

• Indledende svartid: Den første læsning af data resulterer altid i et cache-miss, hvilket gør den langsommere.
• Forældede data: Hvis databasen opdateres direkte, kan cachen indeholde gamle data, indtil de udløber eller ugyldiggøres eksplicit.

Write-Through-mønsteret sikrer, at data skrives til både cachen og det primære datalager (databasen) samtidig. Applikationen skriver til cachen, og cachen er ansvarlig for at skrive dataene til databasen.

• Når data skrives, går de først til cachen.
• Cachen skriver derefter straks dataene til databasen.
• Skrivehandlingen betragtes først som fuldført, når begge handlinger lykkes.

Forestil dig, at prisen på et produkt opdateres. Sådan fungerer Write-Through:

1. Applikationen skriver data: Sender den nye produktpris for product:202 til Redis.
2. Cachen skriver til databasen: Redis skriver straks den samme opdatering til databasen.
3. Cachen bekræfter: Redis bekræfter skrivningen over for applikationen, først når skrivningen til databasen er fuldført.
4. Applikationen fortsætter: Applikationen fortsætter, vel vidende at både cache og database er synkroniseret.

Ved Write-Through udfører din applikation typisk én skrivehandling til cachen, hvorefter cachen (eller et klientbibliotek, der implementerer mønsteret) håndterer lagringen i databasen. Her simulerer vi indstilling af en værdi, som konceptuelt også ville opdatere databasen.

Fordele:

• Datakonsistens: Cache og database er altid synkroniserede.
• Pålidelighed: Data gemmes med det samme.
• Enklere læsninger: Alle læsninger er cache-hits (forudsat at data altid skrives via cachen).

Ulemper:

• Skrivesvartid: Skrivninger er langsommere, fordi data skal skrives to gange (cache + database).
• Cacheforurening: Data, der skrives til cachen, bliver måske aldrig læst, så der spildes cacheplads.
• Øget belastning: Hver skrivehandling medfører en skrivning til databasen, hvilket potentielt øger belastningen på databasen.

Godt klaret! Du har lært om to grundlæggende cachestrategier:

• Cache-Aside: Din applikation administrerer cachen. Ved læsninger tjekkes cachen først; ved et miss hentes data fra databasen, gemmes i cachen og returneres derefter. Bedst til læsetunge data.
• Write-Through: Skrivninger går til cachen, som derefter straks skriver til databasen. Sikrer stærk konsistens mellem cache og database.

Disse mønstre danner grundlaget for mere avancerede cacheteknikker, som du udforsker i kommende lektioner!