Cachingstrategier: Lazy Loading og Write-Through

Lazy loading har tre vigtige fordele: Kun efterspurgte data caches — cachen fyldes ikke med data, som ingen læser, så hukommelsen udnyttes effektivt. En tom cache får ikke applikationen til at gå ned — ved cache-misses falder applikationen tilbage til databasen, så applikationen fortsætter med at fungere, selv hvis ElastiCache genstartes, eller en node svigter (dog med højere latenstid). Cachen er altid eventual consistent med databasen, fordi forældede data udløber via TTL, selv hvis opdateringer blev overset.

Lazy loading har tre vigtige ulemper: Cache-misses er dyre — tre handlinger (cache-tjek, databaselæsning og cacheskrivning) i stedet for én ved et cache-træf, hvilket giver højere latenstid for kolde forespørgsler. Forældede data — efter en databaseopdatering leverer cachen stadig den gamle værdi, indtil TTL udløber, eller nøglen udtrykkeligt ugyldiggøres (vinduet med inkonsistente cachedata). Cache-stormløb — hvis en populær nøgle udløber, oplever mange samtidige forespørgsler et cache-miss og rammer databasen samtidig, hvilket potentielt kan overbelaste den.

I strategien write-through skrives enhver skrivning til databasen også til cachen samtidig. Applikationen skriver til både cachen og databasen som en del af den samme handling (eller databasen udløser en cacheopdatering). Cachen er derfor altid synkroniseret med databasen — der er ikke noget vindue med forældede data. Write-through garanterer, at data i cachen altid er opdaterede, så efterfølgende læsninger altid giver cache-træf for data, der for nylig er skrevet.

Fordele ved write-through: Cachedata er altid aktuelle — der er ingen forældede data, fordi cachen opdateres ved hver skrivning. Læsninger er altid hurtige — populære data, der skrives ofte, er altid i cachen. Ingen cache-stormløb ved læsninger — fordi data udfyldes på forhånd, før de læses, er der ingen kolde cache-misses for nyligt skrevne data. Denne strategi er ideel til læsetunge arbejdsbelastninger med hyppige opdateringer, hvor dataaktualitet er afgørende, f.eks. produktkataloger, prissystemer eller caches med brugerprofiler.

Ulemper ved write-through: Skriveomkostning — hver skrivning medfører to handlinger (database + cache), hvilket øger latenstiden for skrivninger. Cacheforurening — data caches, selv om de aldrig læses igen (skrevet én gang, aldrig efterspurgt), så cachehukommelse spildes. Genstart af cachen giver en tom cache — hvis cacheklyngen genstartes, går alle de proaktivt skrevne data tabt, og cachen skal udfyldes igen gennem skrivninger eller en opvarmningsproces. Kombinér write-through med en TTL for at forhindre ubegrænset vækst af sjældent læste cachedata.

I praksis kombinerer mange produktionssystemer begge strategier: Brug write-through til data, der opdateres og læses ofte (f.eks. brugersessioner eller aktuelle priser) og lazy loading til data, der opdateres sjældent, men læses ofte (f.eks. produktbeskrivelser eller artikelindhold). Angiv passende TTL'er for begge: write-through-nøgler får en lang TTL, fordi dataene altid er aktuelle, mens lazy-loaded nøgler får en kortere TTL for at begrænse vinduet med forældede data. Denne hybride tilgang maksimerer cache-træffrekvensen og minimerer forældelse.

Levetiden (TTL) for cachede data styrer det maksimale vindue med forældede data og cachehukommelsens pladsforbrug. Design TTL'er ud fra: dataenes opdateringsfrekvens (sessionsdata ændres ofte → kort TTL; statisk indhold ændres sjældent → lang TTL), tolerancen for forældelse (finansielle priser → meget kort; blogindlæg → timer eller dage) og cachehukommelsens kapacitet (lav hukommelse → kortere TTL, så forældede data fjernes hurtigere). Angiv altid en TTL — cachelagr aldrig data uden udløb, ellers vil cachen til sidst blive fyldt med forældede data.

I stedet for udelukkende at stole på TTL-udløb kan du udtrykkeligt ugyldiggøre (slette) cachenøgler, når de underliggende data ændres. Det fjerner hele vinduet med forældede data. Almindelige mønstre er: sletning ved skrivning (slet cachenøglen efter hver databaseopdatering — den næste læsning udfylder den igen via lazy loading) og hændelsesdrevet ugyldiggørelse (DynamoDB Streams eller ændringsopsamling fra RDS udløser en Lambda, der sletter de berørte nøgler). Ugyldiggørelse af cache er et af de vanskeligste problemer i distribuerede systemer; jo enklere logikken for ugyldiggørelse er, desto mere pålidelig er din cache.

Et mindre almindeligt, men effektivt mønster er write-behind (write-back): Applikationen skriver kun til cachen, og cachen overfører asynkront data til databasen i baggrunden. Det giver ekstremt hurtige skrivninger (kun i hukommelsen) på bekostning af risikoen for datatab, hvis cachen svigter, før dataene er overført. Write-behind egner sig til hyppige skrivninger i stort omfang, hvor dataene kan genskabes, eller hvor små tab kan accepteres — f.eks. tællere for besøg, analysehændelser eller opdateringer af spilresultater. ElastiCache understøtter ikke write-behind direkte; det skal implementeres i applikationslaget.

I denne lektion har du lært, at lazy loading udfylder cachen ved læsemisses og udnytter hukommelsen effektivt, men kan levere forældede data, indtil TTL udløber, at write-through opdaterer cachen ved hver skrivning, så der ikke er forældede data, men spilder hukommelse på ulæste data, og at udtrykkelig ugyldiggørelse sletter cachenøgler ved databaseopdateringer for at fjerne vinduer med forældede data. Næste gang undersøger vi mønstre for sessionslagring og ranglister med ElastiCache.