Hva er hurtigbufring?

Hurtigbufring er praksisen med å lagre nøkkelverdidata i midlertidig minne (for eksempel en ikke-relasjonell strukturert spørringsspråkdatabase (NoSQL-datatbase), slik at programmer kan hente dem raskere enn de kunne fra vanlig lagring. I skylagringsarkitekturer – der forespørsler ofte krysser nettverk og berører delte tjenester – kan hurtigbufring bidra til å holde svartiden lav og redusere gjentatt arbeid.

De fleste systemer har en varig «kilde til sannhet» (en database) for fullstendige datasett, og beholder deretter en hurtigbuffer for midlertidige delsett som leses ofte. Når en forespørsel kommer inn, kontrollerer appen hurtigbufferen først; hvis dataene er der, returneres de raskt uten å spørre serverdelen på nytt. Utviklere bufrer også behandlede data og bruker dem på nytt for å betjene forespørsler raskere enn standardspørringer til relasjonsdatabaser, SQL-databaser eller PostgreSQL-databaser med åpen kildekode.

1. Bufre det du leser mye

Gode kandidater inkluderer data lest gjentatte ganger og data som endres sjelden (for eksempel produkt- og prisinformasjon eller delte statiske ressurser som er kostbare å konstruere).

2. Hurtigbufferresultater for gjentatt arbeid

Hvis en operasjon transformerer data eller utfører en komplisert beregning, kan hurtigbufring av resultatet unngå å kompilere dem på nytt for etterfølgende forespørsler.

3. Bruk hurtigbufferlag ved behov

Utviklere bruker buffere på flere nivåer («bufferlag») til å lagre forskjellige typer data i separate buffere etter behov. Hvis du legger til ett eller flere hurtigbufferlag, kan det forbedre gjennomstrømming og ventetid i et datalag.

4. Hold øktstatusen nær for responsive apper

Minneinterne butikker brukes ofte til å inneholde store mengder øktdata, for eksempel brukerinndata, handlekurvoppføringer eller tilpassingsinnstillinger i korte perioder. For tilstandsfulle apper lagrer team også øktstatus i hurtigbufferen, slik at appen kan være tilstandsløs.

Hurtigbufring kan forbedre ytelsen på noen konkrete måter:

• Å lese data fra en minneintern buffer går mye raskere enn å få tilgang til data fra et diskdrevet datalager.
• Færre spørringer kan redusere belastningen og begrense behovet for å skalere databaseinfrastruktur, noe som også kan redusere kostnadene.
• Hurtigbufferlag kan forbedre gjennomstrømming og ventetid, og hurtigbuffere i minnet kan bidra til å redusere ventetiden under brukstopper.
• En bufferforekomst kan håndtere millioner av forespørsler per sekund, og tilbyr gjennomstrømming som mange databaser ikke kan måle seg med.

I mange skyutforminger ligger en hurtigbuffer ved siden av et primært datalager (for eksempel en database). Det primære lageret inneholder det fullstendige, varige datasettet på skyserveren, mens hurtigbufferen beholder et mindre, midlertidig delsett som er raskere å lese.

Et vanlig oppsett er et frittstående hurtigbufferlag eller en hurtigbuffer som befinner seg innenfor app- eller databasenivået – valgt basert på hvor du trenger raske lesinger.

Noen systemer bruker hurtigbufring på flere nivåer («hurtigbufferlag») slik at ulike typer data befinner seg i forskjellige hurtigbuffere basert på behov. Hvis du legger til ett eller flere hurtigbufferlag, kan det forbedre gjennomstrømmingen og ventetiden for datalaget og redusere totalkostnadene ved å redusere belastningen på serverdelen.

Team bufrer vanligvis data som deles inn i noen få kategorier:

• Ofte leste data (spesielt hvis de endres sjelden), for eksempel produkt- eller prisinformasjon, og delte statiske ressurser som er kostbare å konstruere.
• Gjentatte beregninger, der en operasjon transformerer data eller utfører en komplisert beregning – hurtigbufring av resultatet unngår å gjøre det samme arbeidet på nytt for senere forespørsler.
• Øktstatus for tilstandsfulle apper, der lagring av øktstatus i hurtigbuffer kan bidra til å holde appnivået tilstandsløst.

Det finnes flere standardmåter apper leser fra og skriver til en hurtigbuffer på. Her er de vanligste mønstrene og hva de betyr i praksis.

• Buffer til side: Laste inn data ved behov fra et datalager.
• Les gjennom: Les fra hurtigbufferen, og hurtigbufferen hentes fra datalageret om nødvendig.
• Gjennomskriving: Skriv inn i hurtigbufferen, og den synkroniseres på nytt med datalageret synkront.
• Tilbakeskriving (skrive bak): Skriv inn i hurtigbufferen, og den skriver tilbake til datalageret i grupper.
• Skrive rundt: Skrive inn i datalageret og lese fra hurtigbufferen. Hurtigbufferen oppdateres ved behov.

Bruk av hurtigbufferlag kan forbedre gjennomstrømming og ventetid ved å betjene vanlige forespørsler fra hurtigbufferen i stedet for gjentatte ganger å spørre baklageret. Dette kan redusere behovet for å skalere databaseinfrastrukturen fordi færre forespørsler når databasen i utgangspunktet.

For apper med topper i bruk kan hurtigbuffere i minnet bidra til å redusere ventetiden ved å holde ofte forespurte data nær der de brukes.

Bruk disse som utgangspunkt når du velger en arbeidsflyt:

• Foretrekk buffer til side når appen kan bestemme hva du vil lagre og når den skal oppdateres.
• Foretrekk gjennomlesing når du vil at hurtigbufferen skal håndtere henting fra datalageret «om nødvendig».
• Vurder gjennomskriving eller tilbakeskriving når skriveatferd er viktig, og du vil ha en definert ny synkroniseringstilnærming.

Hurtigbufring forbedrer programytelsen fordi lesing fra en minnehurtigbuffer er raskere enn lesing fra et diskdrevet datalager. Når flere forespørsler behandles fra hurtigbufferen, sender systemer færre spørringer til serverdeldatabaser, noe som kan redusere behovet for å skalere databaseinfrastruktur og redusere relaterte kostnader.

Det du ofte får fra hurtigbufring

• Lavere ventetid for vanlige lesinger, siden ofte forespurte data kommer fra et raskere lag.
• Redusert databasebelastning og -kostnad, fordi hurtigbufring fører til færre databasespørringer og mindre press for å overstyre databaseforekomster.
• Mer forutsigbar gjennomstrømming, siden en hurtigbuffer kan håndtere svært høyt forespørselsvolum sammenlignet med mange databaser.
• Jevnere håndtering av trafikktopper, fordi hurtigbuffere i minnet kan redusere ventetiden i perioder med høy gjennomstrømming.

Hurtigbufring bidrar til å redusere gjentatt arbeid. Data som leses gjentatte ganger – eller som er kostbare å konstruere – kan lagres én gang og brukes på nytt. Hvis en operasjon utfører en komplisert beregning eller transformerer data, reduserer hurtigbufring av resultatet gjentatt beregning for etterfølgende forespørsler.

Vanlige «gode hurtigbuffer»-kandidater

• Data som endres sjelden (for eksempel produkt- og prisinformasjon).
• Delte statiske ressurser som er kostbare å konstruere.
• Resultater av operasjoner som beregnes gjentatte ganger.

Nettsteder: Raskere sideinnlastinger og færre rundturer

Mange områder bufrer sideutdata (for eksempel HTML- og klientskript), slik at serveren kan returnere de bufrede utdataene i stedet for å kjøre sidekoden på nytt hver gang. Hurtigbufring støtter også web-multimediescenarioer via webbuffere og nettverkshurtigbufring, for eksempel innholdsleveringsnettverk (CDN-er).

Typiske bruksområder på nettsteder

• Hurtigbufre hele sideutdata for gjentakelsesvisninger.
• Bufre statiske ressurser via nettverks-/CDN-hurtigbufring.

Apper og API-er: Raskere lesing av delte data

Apper lagrer ofte midlertidige delsett med data i en hurtigbuffer for rask henting, mens den primære databasen beholder det fullstendige varige datasettet. Hurtigbufring av behandlede data og gjenbruk kan betjene forespørsler raskere enn standard databasespørringer.

Vanlige appmønstre

• Hurtigbuffer leser ofte referansedata (for eksempel priser) for å redusere gjentatte databasekall.
• Bufre beregnede resultater for å unngå å gjenta dyrt arbeid.

Servere og tjenester: Skalering av lese- og utjevningstopper

Team legger ofte til ett eller flere hurtigbufferlag for å forbedre gjennomstrømming og ventetid, og betjene vanlige spørringer fra hurtigbufferen og redusere databasebelastningen. Hurtigbuffere i minnet kan hjelpe når brukstopper og krav til gjennomstrømming øker, noe som reduserer ventetiden i disse periodene.

Der dette hjelper mest

• Endepunkter med mange lesinger der de samme nøklene etterspørres ofte.
• Systemer som ser periodiske trafikkøkninger.

Forretningssystemer: Økttilstand og delte driftsdata

Hurtigbufring brukes ofte til å lagre store mengder kortvarige øktdata (for eksempel brukerinndata eller tilpassingsinnstillinger) i et lager i minnet. Noen team lagrer også øktstatus i hurtigbufferen, slik at tilstandsfulle apper kan holde appnivået tilstandsløst. For driftssystemer er data som endres sjelden – for eksempel produkt- og prisinformasjon – et vanlig hurtigbufringsmål.

Eksempler du kan tilordne til arbeidsbelastninger for bedrifter

• Øktdata for nett- og mobilapper (kortvarig, høyt volum).
• Les ofte driftsreferansedata (priser, delte ressurser).

En nettleserhurtigbuffer lagrer kopier av statiske ressurser på en brukers enhet, slik at gjentatte besøk kan bruke disse filene på nytt i stedet for å laste dem ned på nytt.

Vanlige brukstilfeller

• Statiske nettstedsressurser, for eksempel bilder, CSS-filer og JavaScript-filer.
• Reduserer rundturer til opprinnelsesserveren for tidligere hentede ressurser.

Hurtigbufring på serversiden skjer i prosessene som kjører forretningstjenester eksternt, i stedet for på sluttbrukerens enhet. Hurtigbuffere på serversiden er ofte enten private (lokale til én appforekomst) eller delt (brukes av mange appforekomster).

Vanlige brukstilfeller

• Privat hurtigbuffer i minnet i én enkelt prosess for beskjedne mengder statiske data.
• Delt hurtigbuffertjeneste slik at flere appforekomster leser de samme hurtigbufrede verdiene og unngår «forskjellige versjoner» på tvers av forekomster.
• Data som leses ofte, men endres sjelden (for eksempel referansedata for produkter og priser).

En CDN bufrer innhold på kantservere nærmere sluttbrukerne, slik at forespørsler ikke alltid reiser tilbake til opprinnelsen. I motsetning til en nettleserhurtigbuffer (én bruker), deles en CDN-hurtigbuffer – én brukers forespørsel kan fylle ut innhold som en annen bruker senere mottar.

Vanlige brukstilfeller

• Delt levering av innhold som kan bufres fra kantplasseringer for å redusere opprinnelsesforespørsler.
• Statiske ressurser som drar nytte av å bli betjent i nærheten av brukere (samme type aktivaleserhurtigbuffer, men som deles på tvers av brukere).

Hurtigbufring er ikke bare et skydatabehandlingsmønster – maskinvare- og minnelag bruker det også.

CPU-hurtigbuffer er et lite, raskt minneområde nær (eller på) prosessoren som lagrer kopier av ofte brukte data og instruksjoner for å redusere tiden som brukes på å vente på hovedminnet.

Minnebufferen (i minnet) er den enkleste programvarebuffertypen: Et minneinternt lager oppbevares i adresseområdet for én enkelt prosess og åpnes direkte av denne prosessen.

Vanlige brukstilfeller

• CPU-hurtigbuffer: Gjentatt tilgang til de samme instruksjonene/dataene uten hyppige reiser til hovedminnet.
• Hurtigbuffer i minnet: Hurtiglesinger av beskjedne mengder relativt statiske data i én tjeneste som kjører.

En distribuert hurtigbuffer strekker seg over flere servere, slik at hurtigbufferen kan vokse og få transaksjonskapasitet utover én maskin. Mange delte hurtigbuffertjenester bruker en klynge med servere og distribuerer bufrede data på tvers av klyngen. skalering av hurtigbufferen kan være så enkelt som å legge til flere servere. Noen distribuerte utforminger legger også laghurtigbufre, slik at en feil på ett lag trekker fra en oppstrømsleverandør og lagrer deretter resultatet lokalt for neste forespørsel.

Vanlige brukstilfeller

• Et delt hurtigbuffernivå for flere appforekomster og -maskiner.
• Arbeidsbelastninger som trenger bufferkapasitet og gjennomstrømming som overskrider én enkelt vert.
• Lagvise hurtigbufferoppsett der feil hentes fra oppstrøms og deretter beholder en lokal kopi for etterfølgende forespørsler.

Hurtigbufring holder ofte brukte data nærmere der de brukes, noe som kan forbedre responstiden og hjelpe et system med å håndtere mer samtidige forespørsler. Det kan også redusere konflikt i det opprinnelige datalageret, for eksempel når en database har begrensede tilkoblinger.

I distribuerte programmer skjer hurtigbufring ofte på mer enn ett sted – klientsiden (for eksempel en nettleser) og serversiden (i et program eller en delt hurtigbuffertjeneste).

Start i det små og fokuser på dataene som gir deg den klareste returen:

• Bufre lesetunge, sakte-å-hente-data som endres sjelden (for eksempel referansedata).
• Bestem når data kommer inn i hurtigbufferen:
  • På forespørsel etter den første forespørselen, så du lagrer bare det som faktisk brukes.
  • Forhåndsutfyll (seed) noen elementer ved oppstart hvis du vet at de blir forespurt tidlig – samtidig som du ser etter oppstartsbelastning i den opprinnelige butikken.
• Velg et mønster du kan administrere. Mønsteret for buffer til side er vanlig, og veiledningen fremhever hvordan utløp, utestengelse og konsekvens påvirker resultatene.

En hurtigbuffer inneholder vanligvis kopier av data fra et primærlager, slik at ferskhet krever oppmerksomhet:

• Bruk utløpspolicyer til å begrense hvor lenge data kan forbli i hurtigbufferen før de oppdateres.
• Se slettingsvirkemåte når hurtigbuffere fylles opp (mange systemer kaster ut minst nylig brukte elementer som standard).
• Ikke behandle hurtigbufferen som det eneste hjemmet for kritiske data. Behold kilden til sannheten i vedvarende lagring, slik at systemet kan fortsette hvis hurtigbufferen ikke er tilgjengelig.
• Planlegg en tilbakefallsbane til det opprinnelige datalageret, hvis hurtigbufferen ikke kan nås og fylles ut på nytt når lesinger forekommer.

Hurtigbufring er en kjernebyggekloss for moderne systemer, fordi den passer til mange arkitekturer – fra enkelttjenester til distribuerte apper og kantlevering. For en administrert skyleverandør i minnehurtigbufferen kan du utforske Azure.