Roshan Kumar er senior produktsjef i Redis Labs.
Redis Streams er en ny datastruktur, introdusert i Redis 5.0, som lar deg opprette og administrere datastrømmer. I en tidligere artikkel viste jeg hvordan du legger til data i en strøm, og hvordan du leser dataene på flere måter. I denne artikkelen vil jeg forklare hvordan du bruker forbrukergrupper i Redis Streams. En forbrukergruppe er en måte å dele en strøm av meldinger på mellom flere klienter for å øke behandlingen eller lette belastningen for tregere forbrukere.
I en perfekt verden jobber både dataprodusenter og forbrukere i samme tempo, og det er ingen tap av data eller dataetterslep. Dessverre er det ikke tilfelle i den virkelige verden. I nesten alle sanntidsbehandlingssaker for datastrøm, jobber produsenter og forbrukere i forskjellige hastigheter. I tillegg er det mer enn én type forbrukere, hver med sine egne krav og prosesseringstempo. Redis Streams adresserer dette behovet med et funksjonssett som graverer tungt mot å støtte forbrukerne. En av de viktigste funksjonene er forbrukergruppen.
Når skal jeg bruke en Redis Streams forbrukergruppe
Formålet med forbrukergrupper er å skalere prosessen for dataforbruk. La oss se på et eksempel - en applikasjon for bildebehandling. Løsningen krever tre hovedkomponenter:
- En produsent (ett eller flere kameraer, kanskje) som tar og lagrer bilder;
- Redis Stream som lagrer bilder (i en stream-datalager) i den rekkefølgen de kommer; og
- En bildeprosessor som behandler hvert bilde.
Redis Labs Anta at produsenten din sparer 500 bilder per sekund, og bildeprosessoren behandler bare 100 bilder per sekund med full kapasitet. Denne hastighetsforskjellen vil skape et etterslep, og bildeprosessoren din vil aldri være i stand til å ta igjen. En enkel måte å løse dette problemet på er å kjøre fem bildebehandlere (som vist i figur 2), som hver behandler et gjensidig utelukkende sett med bilder. Du kan oppnå dette gjennom en forbrukergruppe, som gjør det mulig å fordele arbeidsbelastningen og dirigere dem til forskjellige forbrukere.
Redis Labs En forbrukergruppe gjør mer enn datadelingering - det sikrer datasikkerhet og muliggjør katastrofegjenoppretting.
Hvordan en Redis Streams forbrukergruppe fungerer
En forbrukergruppe er en datastruktur i en Redis Stream. Som vist i figur 3 kan du tenke på en forbrukergruppe som en samling lister. En annen ting å forestille seg er en liste over varer som ikke forbrukes av noen forbrukere - for vår diskusjon, la oss kalle dette en "ukonsumert liste." Når data kommer i strømmen, skyves den umiddelbart til den uforbrukte listen.
Redis Labs Forbrukergruppen opprettholder en egen liste for hver forbruker, vanligvis med en søknad vedlagt. I figur 3 har løsningen vår N identiske applikasjoner (App 1, App 2, .... App n) som leser data via henholdsvis Forbruker 1, Forbruker 2, ... Forbruker n.
Når en app leser data ved hjelp av XREADGROUP-kommandoen, fjernes spesifikke dataoppføringer fra den uforbrukte listen og skyves inn i listen over ventende oppføringer som tilhører den respektive forbrukeren. Dermed vil ikke to forbrukere konsumere de samme dataene.
Til slutt, når appen varsler strømmen med XACK-kommandoen, vil den fjerne varen fra forbrukerens ventende oppføringsliste.
Nå som jeg har forklart det grunnleggende om forbrukergrupper, la oss grave dypere i hvordan denne datalevssyklusen fungerer.
Opprette en Redis Streams forbrukergruppe
Du kan opprette en ny forbrukergruppe ved hjelp av kommandoen XGROUP CREATE, som vist nedenfor.
XGROUP CREATE mystream mygroup $ MKSTREAM
Som med XREAD, forteller et $ -tegn på slutten av kommandoen strømmen å levere bare nye data fra det tidspunktet fremover. Det alternative alternativet er 0 eller en annen ID fra strømoppføringen. Når du bruker 0, vil strømmen levere all data fra begynnelsen av strømmen.
MKSTREAM oppretter en ny strøm, mystream i dette tilfellet, hvis den ikke allerede eksisterer.
Lese og administrere Redis Stream-data
Anta at du har en Redis Stream (mystream), og at du allerede har opprettet en forbrukergruppe (min gruppe) som vist ovenfor. Du kan nå legge til elementer med navnene a, b, c, d, e som i eksemplet nedenfor.
XADD mystream * navn a
Å kjøre denne kommandoen for navn a til e vil fylle ut Redis Stream, mystream og den uforbrukte listen til forbrukergruppen mystream. Dette er illustrert i figur 4.
Redis Labs Her kan du se at forbrukerne Alice og Bob ikke har startet jobbene sine ennå. App A forbruker data gjennom forbrukeren Alice, mens App B bruker data gjennom Bob.
Forbruker Redis Streams-data
Kommandoen for å lese data fra en gruppe er XREADGROUP. I vårt eksempel, når App A begynner å behandle data, ringer den forbrukeren (Alice) til å hente data, som i:
XREADGROUP GROUP mygroup COUNT 2 Alice STREAMS mystream>
På samme måte leser App B dataene via Bob, som følger:
XREADGROUP GROUP mygroup COUNT 2 Bob STREAMS mystream>
Spesialtegnet> på slutten forteller Redis Streams å hente bare dataoppføringer som ikke leveres til andre forbrukere. Vær også oppmerksom på at ikke to forbrukere vil konsumere de samme dataene, noe som vil resultere i å flytte data fra den uforbrukte listen til Alice og Bob som vist i figur 5.
Redis Labs Fjerne behandlede meldinger fra ventende oppføringslister
Dataene i de ventende oppføringslistene til forbrukerne dine vil forbli der til App A og App B anerkjenner Redis Streams at de har konsumert dataene. Dette gjøres ved hjelp av kommandoen XACK. For eksempel vil App A erkjenne som følger etter inntak av d og e, som har ID-ene 1526569411111-0 og 1526569411112-0.
XACK mystream mygroup 1526569411111-0 1526569411112-0
Kombinasjonen av XREADGROUP og XACK er analog med å starte en transaksjon og begå den, noe som sikrer datasikkerhet.
Etter å ha kjørt XACK, la oss anta at App A utførte XREADGROUP som vist nedenfor. Nå ser datastrukturen ut som figur 6.
XREADGROUP GROUP mygroup COUNT 2 Alice STREAMS mystream>
Redis Labs Gjenopprette fra feil
Hvis App B ble avsluttet på grunn av feil under behandling av b og c, ville datastrukturen se ut som figur 7.
Redis Labs Nå sitter du igjen med to alternativer:
1. Start appen B på nytt og last inn dataene fra forbrukeren (Bob).
I dette tilfellet må App B lese data fra forbrukeren (Bob) ved hjelp av kommandoen XREADGROUP, men med en forskjell. I stedet for> på slutten, ville App B passere 0 (eller ID-en lavere enn forrige dataoppføring som ble behandlet). Husk at> sender nye data fra den uforbrukte listen til forbrukeren.
XREADGROUP GROUP mygroup COUNT 2 Bob STREAMS mystream 0
Ovennevnte kommando vil hente dataoppføringer som allerede er lagret i listen for forbruker Bob. Den vil ikke hente nye data fra den uforbrukte listen. App B kunne gjenta alle dataene i forbrukeren Bob før de hentet nye data.
2. Tving Alice til å kreve alle dataene fra Bob og behandle dem via App A.
Dette er spesielt nyttig hvis du ikke kan gjenopprette App B på grunn av node-, disk- eller nettverksfeil. I slike tilfeller kan enhver annen forbruker (som Alice) kreve Bobs data og fortsette å behandle disse dataene, og dermed forhindre nedetid på tjenesten. For å gjøre krav på Bobs data, må du kjøre to sett med kommandoer:
XPENDING mystream mygroup - + 10 Bob
Dette vil hente alle ventende dataoppføringer for Bob. Alternativene - og + henter hele området. Hvis b og c hadde henholdsvis ID-ene 1526569411113-0 og 1526569411114-0, er kommandoen som vil flytte Bobs data til Alice som følger:
XCLAIM mystream mygroup Alice 0 1526569411113-0 1526569411114-0
Forbrukergrupper har en løpende klokke for data i den forbrukte listen. For eksempel, når App B leser b, sparker klokken inn til Bob mottar ACK. Med tidsalternativet i XCLAIM-kommandoen kan du fortelle forbrukergruppen å bare flytte data som er inaktive lenger enn en spesifisert tid. Du kan også ignorere det ved å passere 0 som vist i eksemplet ovenfor. Resultatet av disse kommandoene er illustrert i figur 8. XCLAIM er også nyttig når en av forbrukerprosessorene dine er treg, noe som resulterer i et etterslep av ubehandlede data.
Redis Labs I forrige artikkel dekket vi det grunnleggende om hvordan du bruker Redis Streams. Vi gikk litt dypere i denne artikkelen og forklarte når du skulle bruke forbrukergrupper og hvordan de fungerer. Forbrukergrupper i Redis Streams reduserer belastningen når det gjelder administrering av datapartisjoner, deres livssyklus og datasikkerhet. I tillegg kan utvidelsesegenskapene til forbrukergrupper være til fordel for mange applikasjoner i sanntid.
I en kommende tredje artikkel om Redis Streams vil jeg demonstrere hvordan jeg kan utvikle en sanntids klassifiseringsapplikasjon ved hjelp av Redis Streams and Lettuce, et Java-basert open source-bibliotek for Redis. I mellomtiden kan du lære mer ved å jobbe gjennom Redis Streams-opplæringen på Redis-prosjektnettstedet.
Roshan Kumar er senior produktsjef iRedis Labs. Han har lang erfaring innen programvareutvikling og teknologimarkedsføring. Roshan har jobbet i Hewlett-Packard og mange vellykkede oppstartsbedrifter i Silicon Valley, inkludert ZillionTV, Salorix, Alopa og ActiveVideo. Som en entusiastisk programmerer designet og utviklet han mindzeal.com, en online plattform som er vert for dataprogrammeringskurs for unge studenter. Roshan har en bachelorgrad i informatikk og en MBA fra Santa Clara University.
—
New Tech Forum er et sted for å utforske og diskutere ny teknologi i enestående dybde og bredde. Valget er subjektivt, basert på vårt valg av teknologiene vi mener er viktige og av størst interesse for leserne. godtar ikke markedsføringssikkerhet for publisering og forbeholder seg retten til å redigere alt bidratt innhold. Send alle henvendelser til[email protected].
