Roshan Kumar er senior produktsjef i Redis Labs.
Måling er ikke bare et enkelt telleproblem. Måling forveksles ofte med måling, men det er vanligvis mer enn det. Måling innebærer måling, men som en pågående prosess, vanligvis med målet å regulere bruken eller strømmen av en ressurs over tid. Moderne applikasjoner inkluderer måling på mange forskjellige måter, alt fra å telle mennesker, objekter eller hendelser til å regulere bruken, kontrollere tilgang og tildele kapasitet.
Målerløsninger må generelt behandle store datamengder mens de oppfyller strenge ytelseskrav. Avhengig av løsningens omfang, kan telling og måling involvere tusenvis om ikke millioner av oppdateringer til en database hvert sekund. De primære kravene til en database for å støtte en slik løsning er høy gjennomstrømning for skriveoperasjoner og lav ventetid (under millisekund) for svar.
Redis, åpen kildekode-minne-databaseplattform, gir begge disse fordelene, samtidig som det er kostnadseffektivt når det gjelder å bruke minimale maskinvareressurser. I denne artikkelen vil vi undersøke visse funksjoner i Redis som gjør det til et godt valg for målerløsninger, og hvordan vi kan bruke Redis til det formålet. Men først, la oss se på noen av de vanligste bruksområdene med måling.
Vanlige måleprogrammer
Måling er nødvendig i alle applikasjoner som måler bruken av en ressurs over tid. Her er fire vanlige scenarier:
- Forbruksbaserte prismodeller. I motsetning til engangs- eller abonnementsbaserte betalingsmodeller tillater forbruksbaserte prismodeller forbrukere å betale bare for faktisk bruk. Forbrukere har større fleksibilitet, frihet og kostnadsbesparelser mens leverandører får større forbrukerretensjon.
Å implementere slike modeller kan være vanskelig. Noen ganger målesystemet må spore mange brukselementer og mange beregninger i en enkelt plan. For eksempel kan en skyleverandør angi forskjellige prisnivåer for CPU-sykluser, lagring, gjennomstrømning, antall noder eller hvor lang tid en tjeneste brukes. Et telekommunikasjonsselskap kan angi forskjellige nivåer av tillatt forbruk i minutter, data eller tekst. Målerløsningen må håndheve capping, lading eller utvide tjenester avhengig av typen forbruksbasert pris.
- Begrensning av ressursutnyttelse. Hver tjeneste på Internett kan misbrukes ved overdreven bruk, med mindre denne tjenesten er begrenset. Populære tjenester som Google AdWords API og Twitter Stream API inneholder takstgrenser av denne grunn. Noen ekstreme tilfeller av misbruk fører til nektelse av tjeneste (DoS). For å forhindre misbruk må tjenester og løsninger som er tilgjengelige på Internett utformes med riktige hastighetsbegrensende regler. Selv enkle autentiserings- og påloggingssider må begrense antall forsøk i et gitt tidsintervall.
Et annet eksempel der begrensning av ressursutnyttelse blir nødvendig, er når endrede forretningskrav legger større belastning på eldre systemer enn de kan støtte. Takstbegrensende samtaler til eldre systemer gjør det mulig for bedrifter å tilpasse seg den økende etterspørselen uten å måtte erstatte sine eldre systemer.
I tillegg til å forhindre misbruk og redusere belastning, hjelper god hastighetsbegrensning også med håndteringen av tøffe trafikkscenarier. For eksempel kan et API som håndhever en hastighetsbegrensende metode for brute force tillate 1000 samtaler hver time. Uten en trafikkformende policy på plass, kan en klient ringe API 1000 ganger i løpet av de første sekundene av hver time, kanskje overstige det infrastrukturen kan støtte. Populære hastighetsbegrensende algoritmer som Token Bucket og Leaky Bucket forhindrer utbrudd ved ikke bare å begrense samtalene, men også distribuere dem over tid.
- Ressursfordeling. Trengsel og forsinkelser er vanlige scenarier i applikasjoner som håndterer pakkeruting, jobbadministrasjon, trafikkbelastning, mengdekontroll, sosiale meldinger, datainnsamling og så videre. Kømodeller tilbyr flere alternativer for å administrere køstørrelsen basert på ankomst- og avgangshastigheten, men det er ikke enkelt å implementere disse modellene i stor skala.
Etterslep og overbelastning er konstant bekymring når du arbeider med raske datastrømmer. Smarte designere må definere akseptable kølengdsgrenser, mens de inkluderer både overvåking av køytelse og dynamisk ruting basert på køstørrelser.
- Teller i stor skala for beslutningstaking i sanntid. Netthandelssider, spillapplikasjoner, sosiale medier og mobilapper tiltrekker seg millioner av daglige brukere. Fordi flere øyeepler gir større inntekter, er det viktig for virksomheten å telle besøkende og deres handlinger nøyaktig. Telling er like nyttig for brukstilfeller som feilsøking, problemopptrapping, DDoS-angrepsforebygging, trafikkprofilering, ressursallokering etter behov og svindelreduksjon.
Måling design utfordringer
Løsningsarkitekter må vurdere mange parametere når de bygger en måleapplikasjon, og starter med disse fire:
- Designkompleksitet. Å telle, spore og regulere datamengder - spesielt når de kommer med høy hastighet - er en skremmende oppgave. Løsningsarkitekter kan håndtere måling ved applikasjonslaget ved hjelp av programmeringsspråkstrukturer. Imidlertid er en slik design ikke motstandsdyktig mot feil eller datatap. Tradisjonelle diskbaserte databaser er robuste, og lover en høy grad av holdbarhet under feil. Men ikke bare gir de ikke den nødvendige ytelsen, de øker også kompleksiteten uten riktige datastrukturer og verktøy for å implementere måling.
- Ventetid. Måling innebærer vanligvis mange, konstante oppdateringer av tellinger. Nettverks- og diskens lese- / skrivelatens legger seg opp mens du arbeider med store tall. Dette kan snøball i å bygge opp et enormt etterslep med data som fører til flere forsinkelser. Den andre kilden til ventetid er et programdesign som laster inn måledata fra en database til programmets hovedminne, og skriver tilbake til databasen når du er ferdig med å oppdatere telleren.
- Samtidighet og konsistens. Arkitektur av en løsning for å telle millioner og milliarder av ting kan bli komplisert når hendelser blir fanget i forskjellige regioner, og de trenger alle å samles på ett sted. Datakonsistens blir et problem hvis mange prosesser eller tråder oppdaterer det samme antallet samtidig. Låsingsteknikker unngår konsistensproblemer og gir konsistens på transaksjonsnivå, men reduserer løsningen.
- Varighet. Måling påvirker inntektstallene, noe som innebærer at kortvarige databaser ikke er ideelle når det gjelder holdbarhet. En minnelager med holdbarhetsalternativer er et perfekt valg.
Bruker Redis til måleprogrammer
I de følgende avsnittene vil vi undersøke hvordan du bruker Redis til telling og måling av løsninger. Redis har innebygde datastrukturer, atomkommandoer og time-to-live (TTL) -funksjoner som kan brukes til å bruke strømmålere. Redis går på en enkelt tråd. Derfor serialiseres alle databaseoppdateringene, slik at Redis kan fungere som et låsfritt datalager. Dette forenkler applikasjonsdesignet ettersom utviklere ikke trenger å bruke noe på å synkronisere trådene eller implementere låsemekanismer for datakonsistens.
Atomic Redis kommandoer for telling
Redis gir kommandoer for å øke verdiene uten å måtte lese dem til programmets hovedminne.
| Kommando | Beskrivelse |
|---|---|
INCR nøkkel | Øk heltalsverdien til en nøkkel en |
INCRBY nøkkeltilvekst | Øk heltallverdien til en nøkkel med det angitte tallet |
INCRBYFLOAT nøkkeltilvekst | Øk flyteverdien til en nøkkel med det gitte beløpet |
DECR nøkkel | Reduser heltallverdien til en nøkkel en |
FORKJENNELSE nøkkelreduksjon | Reduser heltallverdien til en nøkkel med det angitte tallet |
HINCRBY nøkkelfeltøkning | Øk heltallet til et hash-felt med det angitte tallet |
HINCRBYFLOAT økning i nøkkelfelt | Øk flyteverdien til et hash-felt med det gitte beløpet |
Redis lagrer heltall som et base-10 64-bits signert heltall. Derfor er maksimumsgrensen for et helt tall et veldig stort tall: 263 - 1 = 923372,036,854,775,807.
Innebygd time-to-live (TTL) på Redis-tastene
En av de vanligste brukssakene i måling er å spore bruken mot tid og å begrense ressursene etter at tiden løper ut. I Redis kan man sette en time-to-live-verdi for tastene. Redis vil automatisk deaktivere tastene etter en angitt tidsavbrudd. Tabellen nedenfor viser flere metoder for utløp av nøkler.
| Kommando | Beskrivelse |
|---|---|
UTLØPE nøkkel sekunder | Angi tidspunktet for nøkkelen til å leve i sekunder |
UTLØP nøkkel tidsstempel | Angi utløpet for en nøkkel som et Unix-tidsstempel |
PEXPIRE viktige millisekunder | Angi nøkkeltiden til å leve i millisekunder |
PEXPIREAT nøkkel tidsstempel | Angi utløpet for en nøkkel som et UNIX-tidsstempel i millisekunder |
SETT nøkkelverdi [EX sekunder] [PX millisekunder] | Sett strengverdi til en nøkkel sammen med valgfri tid for å leve |
Meldingene nedenfor gir deg tid til å leve på tastene når det gjelder sekunder og millisekunder.
| Kommando | Beskrivelse |
|---|---|
TTL nøkkel | Få tid til å leve for en nøkkel |
PTTL nøkkel | Få tid til å leve for en nøkkel i millisekunder |
Redis datastrukturer og kommandoer for effektiv telling
Redis er elsket for sine datastrukturer som lister, sett, sorterte sett, hash og hyperloglogger. Mange flere kan legges til via Redis moduler API.
Redis Labs Redis datastrukturer kommer med innebygde kommandoer som er optimalisert for å utføre med maksimal effektivitet i minnet (akkurat der dataene er lagret). Noen datastrukturer hjelper deg med å oppnå mye mer enn å telle objekter. For eksempel garanterer Set-datastrukturen unikhet til alle elementene.
Sortert sett går et skritt videre ved å sikre at bare unike elementer blir lagt til settet, og lar deg bestille elementene basert på en score. Å bestille elementene dine etter tid i en sortert sett datastruktur, for eksempel, vil tilby deg en tidsseriedatabase. Ved hjelp av Redis-kommandoer kan du få elementene dine i en bestemt rekkefølge, eller slette elementer du ikke trenger lenger.
Hyperloglog er en annen spesiell datastruktur som estimerer antall millioner unike ting uten å måtte lagre gjenstandene selv eller påvirke minnet.
| Data struktur | Kommando | Beskrivelse |
|---|---|---|
| Liste | LLEN nøkkel | Få lengden på en liste |
| Sett | SCARD nøkkel | Få antall medlemmer i et sett (kardinalitet) |
| Sortert sett | ZCARD nøkkel | Få antall medlemmer i et sortert sett |
| Sortert sett | ZLEXCOUNT nøkkel min maks | Tell antall medlemmer i et sortert sett mellom et gitt leksikografisk område |
| Hash | HLEN nøkkel | Få antall felt i en hash |
| Hyperlogg | PFCOUNT nøkkel | Få den omtrentlige kardinaliteten til settet observert av Hyperloglog-datastrukturen |
| Bitmap | BITCOUNT tast [start slutt] | Teller settbiter i en streng |
Redis utholdenhet og replikering i minnet
Måling av brukstilfeller som betalinger innebærer lagring og oppdatering av informasjon som er viktig for bedrifter. Tap av data har direkte innvirkning på inntektene. Det kan også ødelegge faktureringsoppføringer, som ofte er et krav til samsvar eller styring.
Du kan stille konsistens og holdbarhet i Redis basert på dine datakrav. Hvis du trenger et permanent bevis for måling av dataene dine, kan du oppnå holdbarhet gjennom Redis utholdenhetsfunksjoner. Redis støtter AOF (kun append-fil), som kopierer skrivekommandoer til disken mens de skjer, og snapshotting, som tar dataene slik de eksisterer på et øyeblikk og skriver dem til disken.
Innebygd låsfri Redis-arkitektur
Redis-behandlingen er enkelt gjenget; Dette sikrer dataintegritet, ettersom alle skrivekommandoer automatisk blir seriellisert. Denne arkitekturen avlaster utviklerne og arkitektene fra byrden ved å synkronisere tråder i et flertrådet miljø.
Når det gjelder en populær mobilapp for forbrukere, kan tusenvis og noen ganger millioner av brukere få tilgang til applikasjonen samtidig. La oss si at applikasjonen måler tiden som brukes, og to eller flere brukere kan dele minutter samtidig. De parallelle trådene kan oppdatere det samme objektet uten å påføre den ekstra byrden å sikre dataintegriteten. Dette reduserer kompleksiteten i applikasjonsdesignen, samtidig som det sikres hastighet og effektivitet.
Redis måleeksempelimplementeringer
La oss ta en titt på eksempelkoden. Flere av scenariene nedenfor vil kreve svært komplekse implementeringer hvis databasen som ble brukt ikke var Redis.
Blokkerer flere påloggingsforsøk
For å forhindre uautorisert tilgang til kontoer, blokkerer nettsteder noen ganger brukere fra å gjøre flere påloggingsforsøk innen en angitt tidsperiode. I dette eksemplet begrenser vi brukerne fra å gjøre mer enn tre påloggingsforsøk på en time ved hjelp av enkel nøkkel-tid-til-live-funksjonalitet.
Nøkkelen til å holde antall påloggingsforsøk:
bruker_innloggingsforsøk:
Fremgangsmåte:
Få gjeldende antall forsøk:
FÅ bruker_innloggingsforsøk:
Hvis null, så sett nøkkelen med utløpstiden i sekunder (1 time = 3600 sekunder):
SET bruker_innloggingsforsøk: 1 3600
Hvis ikke null, og hvis antallet er større enn 3, kan du kaste en feil:
Hvis ikke null, og hvis antallet er mindre enn eller lik 3, øk antallet:
INCR bruker_innloggingsforsøk:
Ved et vellykket påloggingsforsøk kan nøkkelen slettes som følger:
DEL bruker_innloggingsforsøk:
Betal når du går
Redis Hash-datastrukturen gir enkle kommandoer for å spore bruk og fakturering. La oss anta at hver kunde har faktureringsdataene sine lagret i en Hash, som vist nedenfor:
kunde_fakturering:bruk
koste
.
.
Anta at hver enhet koster to øre, og brukeren spiste 20 enheter. Kommandoene for å oppdatere bruk og fakturering er:
hincrby-kunde: bruk 20hincrbyfloat-kunde: kostnad .40
Som du kanskje har lagt merke til, kan applikasjonen din oppdatere informasjonen i databasen uten å kreve at den laster inn dataene fra databasen i sitt eget minne. I tillegg kan du endre et enkelt felt i et Hash-objekt uten å lese hele objektet.
Merk: Formålet med dette eksemplet er å vise hvordan du bruker hincrby og hincrbyfloat kommandoer. I god design unngår du å lagre overflødig informasjon som både bruk og pris.
