Hvad er cachelagring?

Cachelagring er den praksis, hvor nøgleværdidata lagres i midlertidig hukommelse (f.eks. et ikke-relationelt struktureret forespørgselssprog (NoSQL)-database), så programmer kan hente dem hurtigere, end de kunne fra et traditionelt lager. I cloudlagerarkitekturer – hvor anmodninger ofte fungerer på tværs af netværk og berøringsdelte tjenester – cachelagring kan hjælpe med at holde svartiderne lave og reducere gentaget arbejde.

De fleste systemer har en varig “kilde til sandheden” (en database) til komplette delmængder og beholder derefter en cache til midlertidige delmængder, der læses ofte. Når en anmodning kommer ind, kontrollerer appen cachen først. hvis dataene er der, returneres de hurtigt uden at forespørge backend igen. Udviklere cachelagrer også behandlede data og genbruger dem for at behandle anmodninger hurtigere end standardforespørgsler til relationsdatabaser, SQL-databasereller PostgreSQL-databaser med åben kildekode.

1. Cachelagr det, du læser meget

Gode kandidater omfatter data, der læses gentagne gange, og data, der ændres sjældent (f.eks. produkt- og prisoplysninger eller delte statiske ressourcer, der er dyre at konstruere).

2. Cacheresultater af gentaget arbejde

Hvis en handling transformerer data eller udfører en kompliceret beregning, kan cachelagring af resultatet undgå at genberegnes for efterfølgende anmodninger.

3. Brug cachelag, når det er nødvendigt

Udviklere bruger cachelagre på flere niveauer (“cachelag”) til at gemme forskellige typer data i separate cachelagre ud fra behov. Tilføjelse af et eller flere cachelag kan forbedre gennemløb og ventetid i et datalag.

4. Hold sessionstilstanden lukket for dynamiske apps

Lagre i hukommelsen bruges ofte til at opbevare store mængder sessionsdata, f.eks. brugerinput, indkøbskurvposter eller tilpasningsindstillinger i korte perioder. I forbindelse med apps med høj sikkerhed gemmer teams også sessionstilstand i cachen, så appen kan være tilstandsløs.

Cachelagring kan forbedre ydeevnen på et par konkrete måder:

• Det er hurtigere at læse data fra en cache i hukommelsen end at få adgang til data fra et diskdrevet lager.
• Færre forespørgsler kan reducere belastningen og begrænse behovet for at skalere databaseinfrastrukturen, hvilket også kan reducere omkostningerne.
• Cachelag kan forbedre gennemløb og ventetid, og cachelagre i hukommelsen kan hjælpe med at reducere ventetiden under med pludselige stigninger i forbruget.
• En cacheforekomst kan håndtere millioner af anmodninger pr. sekund og tilbyde gennemløb, som mange databaser ikke kan matche.

I mange clouddesign er en cache placeret ved siden af et primært datalager (f.eks. en database). Det primære lager indeholder det komplette, varige datasæt på cloudserver, mens cachen bevarer et mindre, midlertidigt delmængde, der er hurtigere at læse.

En almindelig konfiguration er et separat cachelag eller en cache, der findes i det valgte app- eller databaseniveau – afhængigt af hvor du har brug for hurtige læsninger.

Nogle systemer bruger cachelagring på flere niveauer (“cachelag”), så forskellige typer data findes i forskellige cachelagre ud fra behov. Hvis du tilføjer et eller flere cachelag, kan det forbedre datalagets gennemløb og ventetid og reducere de overordnede omkostninger ved at reducere back end-belastningen.

Teams cachelagrer typisk data, der falder i nogle få buckets:

• Læs ofte data (især hvis de ændres sjældent), f.eks. produkt- eller prisoplysninger, og delte statiske ressourcer, der er dyre at konstruere.
• Gentagne beregninger, hvor en handling transformerer data eller udfører en kompliceret beregning – cachelagring af resultatet undgår, at du udfører det samme arbejde igen for senere anmodninger.
• Sessionstilstand for apps med høj ydeevne, hvor lagring af sessionstilstand i cachen kan hjælpe med at holde appniveauet tilstandsløst.

Apps kan læse fra og skrive til en cache på flere standard måder. Her er de mest almindelige mønstre, og hvad de betyder i praksis.

• Cache-aside: Indlæs data efter behov fra et datalager.
• Gennemlæsning: Læs fra cachen, og cachen henter fra datalageret, hvis det er nødvendigt.
• Write-through-: Skriv i cachen, og den synkroniseres synkront med datalageret.
• Tilbageførsel (bagudskrivning): Skriv til cachen, og den skriver tilbage til datalageret i batcher.
• Write-around: Skriv til datalageret, og læs fra cachen; cachen opdateres efter behov.

Brug af cachelag kan forbedre gennemløb og ventetid ved at betjene almindelige anmodninger fra cachen i stedet for gentagne gange at forespørge back end-lageret. Dette kan reducere behovet for at skalere databaseinfrastrukturen, fordi færre anmodninger når databasen i første omgang.

I forbindelse med apps med pludselige stigninger i forbruget kan cachelagre i hukommelsen hjælpe med at reducere ventetiden ved at holde ofte anmodede data tæt på, hvor de bruges.

Brug disse som udgangspunkt, når du vælger en arbejdsproces:

• Foretræk cache-aside, når din app kan beslutte, hvad du vil gemme, og hvornår den skal opdateres.
• Foretræk gennemlæsning, når cachen skal håndtere hentning fra datalageret, “hvis det er nødvendigt”.
• Overvej at skrive gennem eller skrive tilbage, når skrivefunktionsmåden er vigtig, og du ønsker en defineret tilgang til gensynkronisering.

Cachelagring forbedrer programmets ydeevne, fordi læsning fra en cache i hukommelsen er hurtigere end læsning fra et diskdrevent datalager. Når der behandles flere anmodninger fra cachen, sender systemer færre forespørgsler til back end-databaser, hvilket kan reducere behovet for at skalere databaseinfrastrukturen og reducere relaterede omkostninger.

Det, du ofte får ud af cachelagring

• Lavere ventetid for almindelige læsninger, da ofte anmodede data kommer fra et hurtigere lag.
• Mindre databasebelastning og lavere omkostninger, fordi cachelagring medfører færre databaseforespørgsler og mindre pres på overprovisioning af databaseforekomster.
• Mere forudsigeligt gennemløb, da en cache kan håndtere en meget høj anmodningsmængde sammenlignet med mange databaser.
• Mere problemfri håndtering af pludselige stigninger i trafikken, fordi cachelagre i hukommelsen kan mindske ventetiden under perioder med højt gennemløb.

Cachelagring hjælper med at klippe gentaget arbejde. Data, der læses gentagne gange – eller som er dyre at konstruere – kan gemmes én gang og genbruges. Hvis en handling udfører en kompliceret beregning eller transformerer data, reducerer cachelagring af resultatet gentagen beregning for efterfølgende anmodninger.

Almindelige “gode cachekandidater”

• Data, der ændres sjældent (f.eks. produkt- og prisoplysninger).
• Delte statiske ressourcer, der er dyre at konstruere.
• Resultater af handlinger, der beregnes gentagne gange.

Websteder: Hurtigere sideindlæsninger og færre rundture

Mange websteder cachelagrer sideoutput (f.eks. HTML og klientscripts), så serveren kan returnere det cachelagrede output i stedet for at køre sidekoden igen hver gang. Cachelagring understøtter også scenarier med web multimedier via webcachelagring og netværkscachelagring, såsom netværk, der leverer indhold (CDN'er).

Typiske anvendelser på websteder

• Cachelagring af fuldsideoutput for gentagne visninger.
• Cachelagring af statiske aktiver via netværks-/CDN-cachelagring.

Apps og API'er: Hurtigere læsning af delte data

Apps gemmer ofte midlertidige delmængder af data i en cache til hurtig hentning, mens den primære database bevarer det komplette varige datasæt. Cachelagring af behandlede data og genbrug af dem kan behandle anmodninger hurtigere end standarddatabaseforespørgsler.

Almindelige appmønstre

• Cachen læser ofte referencedata (f.eks. priser) for at reducere gentagne databasekald.
• Cachen beregnede resultater for at undgå at gentage dyrt arbejde.

Servere og tjenester: Skalering af læsninger og udjævning af pludselige stigninger

Teams tilføjer ofte et eller flere cachelag for at forbedre gennemløb og ventetid ved at behandle almindelige forespørgsler fra cachen og reducere databasebelastningen. Cachelagre i hukommelsen kan hjælpe, når forbruget stiger, og behovet for gennemløb stiger, og det mindsker ventetiden i disse perioder.

Hvor dette hjælper mest

• Slutpunkter med høj læseadgang, hvor der ofte anmodes om de samme nøgler.
• Systemer, der ser periodiske serier af trafik.

Virksomhedssystemer: Sessionstilstand og delte driftsdata

Cachelagring bruges ofte til at gemme store mængder kortvarige sessionsdata (f.eks. brugerinput eller indstillinger for område for personlig tilpasning) i et lager i hukommelsen. Nogle teams gemmer også sessionstilstand i cachen, så apps med høj ydeevne kan holde appniveauet tilstandsløst. I forbindelse med operativsystemer er data, der ændres sjældent – såsom produkt- og prisoplysninger – et almindeligt cachelagringsmål.

Eksempler, du kan knytte til arbejdsbelastninger i virksomheden

• Sessionsdata til web- og mobilapps (kortvarig, høj volumen).
• Læs ofte driftsreferencedata (priser, delte ressourcer).

En browsercache gemmer kopier af statiske ressourcer på en brugers enhed, så gentagne besøg kan genbruge disse filer i stedet for at downloade dem igen.

Almindelige anvendelsesområder

• Statiske webstedsaktiver, såsom billeder, CSS-filer og JavaScript-filer.
• Reduktion af rundture til oprindelsesserveren for tidligere hentede ressourcer.

Cachelagring på serversiden sker i de processer, der kører forretningstjenester eksternt, i stedet for på slutbrugerens enhed. Cacher på serversiden er ofte enten private (lokale til én appinstans) eller delt (bruges af mange appforekomster).

Almindelige anvendelsesområder

• Privat cache i hukommelsen i en enkelt proces til store mængder statiske data.
• Delt cachetjeneste, så flere appforekomster læser de samme cachelagrede værdier og undgår “forskellige versioner” på tværs af forekomster.
• Data, der læses ofte, men ændres sjældent (f.eks. referencedata for produkter og priser).

Et CDN cachelagrer indhold på edge-servere tættere på slutbrugerne, så anmodninger ikke altid går tilbage til oprindelsen. I modsætning til en browsercache (én bruger) deles en CDN-cache – én brugers anmodning kan udfylde indhold, som en anden bruger senere modtager.

Almindelige anvendelsesområder

• Delt levering af indhold, der kan cachelagres, fra edge-placeringer for at reducere anmodninger til den oprindelige server.
• Statiske ressourcer, der drager fordel af at blive betjent i nærheden af brugere (de samme typer aktiver, som browsere cachelagrer, men som deles på tværs af brugere).

Cachelagring er ikke kun etcloudcomputing-mønster, – hardware og hukommelseslag bruger det også.

CPU-cache er et lille, hurtigt hukommelsesområde nær (eller i) processoren, der gemmer kopier af ofte anvendte data og instruktioner for at reducere den tid, der bruges på at vente på hovedhukommelsen.

Cache (i hukommelsen) er den mest enkle softwarecachetype: Et lager i hukommelsen, der ligger i adresseområdet for en enkelt proces og tilgås direkte af den pågældende proces.

Almindelige anvendelsesområder

• CPU-cache: Gentagen adgang til de samme instruktioner/data uden hyppige rejser til hovedhukommelsen.
• Cache i hukommelsen: Hurtige læsninger af forholdsvist statiske data i én kørende tjeneste.

En distribueret cache strækker sig over flere servere, så cachen kan vokse og transaktionskapaciteten kan øges ud over én maskine. Mange delte cachetjenester bruger en klynge af servere og distribuerer cachelagrede data på tværs af klyngen; skalering af cachen kan være lige så enkelt som at tilføje flere servere. Nogle distribuerede design lagdeler også cachelagre, så et fejltrin på ét lag trækker fra en upstreamudbyder og gemmer derefter resultatet lokalt til den næste anmodning.

Almindelige anvendelsesområder

• Et delt cacheniveau for flere appforekomster og -maskiner.
• Arbejdsbelastninger, der har brug for cachekapacitet og gennemløb, der overstiger en enkelt vært.
• Lagdelte cachekonfigurationer, hvor fejltrin ikke henter fra upstream og derefter beholder en lokal kopi til efterfølgende anmodninger.

Cachelagring holder data, der bruges ofte, tættere på, hvor de bruges, hvilket kan forbedre svartiden og hjælpe et system med at håndtere flere samtidige anmodninger. Det kan også reducere konflikt i det oprindelige datalager, f.eks. når en database har begrænsede forbindelser.

I distribuerede programmer sker cachelagring ofte på mere end ét sted—på klientsiden (f.eks. i en browser) og på serversiden (i et program eller en delt cachetjeneste).

Start i det små, og fokuser på de data, der giver dig den tydeligste afkast:

• Cachedata, der er læsetunge, langsom at hente, ændrer sig sjældent (f.eks. referencedata).
• Beslut, hvornår data kommer ind i cachen:
  • Efter behov efter den første anmodning, så du kun gemmer det, der faktisk bruges.
  • Udfyld (forsyn) nogle elementer på forhånd ved start, hvis du ved, at der bliver anmodet om dem tidligt – mens du holder øje med startbelastningen på det oprindelige lager.
• Vælg et mønster, du kan administrere. Cache-aside-mønsteret er almindeligt, og dets vejledning fremhæver, hvordan udløb, fjernelse og konsistens påvirker resultaterne.

En cache indeholder normalt kopier af data fra et primært lager, så aktualitet kræver opmærksomhed:

• Brug udløbspolitikker til at begrænse, hvor længe data kan blive i cachen, før de opdateres.
• Hold øje med fjernelsesadfærden, når cachelagrene fyldes op (mange systemer fjerner som standard de elementer, der er brugt mindst for nylig).
• Lad være med at betragte cachen som det eneste sted for kritiske data. Bevar sandhedens kilde i et vedvarende lager, så systemet kan fortsætte, hvis cachen ikke er tilgængelig.
• Planlæg en fallback-sti til det oprindelige datalager, hvis cachen ikke kan nås, og udfyld igen, efterhånden som læsninger opstår.

Cachelagring er en central byggesten i moderne systemer, fordi den passer til mange arkitekturer – fra enkelte tjenester til distribuerede apps og edge-levering. Hvis du vil have en cloududbyder med en administreret cache i hukommelsen, kan du udforske Azure.