Redis ZSCAN

Iterer over medlemmene i et sortert sett

Som dere alle vet, er Redis-sorterte sett avledet fra de vanlige settene der hvert medlem er sortert etter sin poengverdi i stigende rekkefølge. Hvis to eller flere medlemmer har samme poengverdi, er de sortert etter leksikografisk rekkefølge. Vanligvis kan medlemmene og poengsummene hentes direkte ved hjelp av ZRANGE-kommandoen. Når du har et stort sortert sett med tusenvis av medlemmer, kan ZRANGE-kommandoen blokkere serveren i lang tid som SMEMBERS og KEYS-kommandoene, noe som er en ulempe. Så, Redis tilbyr en spesiell kommando kalt ZSCAN som er avledet fra SCAN-kommandoen for å iterere over medlemmene i et sortert sett. Siden ZSCAN-kommandoen arver fra SCAN-kommandoen, er nesten all virkemåte den samme som den generelle SCAN-kommandoen.

Som i den gitte figuren er SCAN-kommandoen en markørbasert iterator. Derfor tar det en eller flere iterasjoner for å gi alle elementene i en Redis-samling. Siden ZSCAN-kommandoen arver fra den overordnede SCAN-kommandoen, er oppførselen den samme. I denne veiledningen vil syntaksen og brukstilfellene til ZSCAN-kommandoen bli diskutert i detalj.

ZSCAN-kommandoen

ZSCAN-kommandoen er en markørbasert iterator som starter iterasjonen med den 0. markøren. Etterpå, i hver iterasjon, returnerer den null eller flere sorterte settmedlemmer sammen med neste markør som skal brukes som markør for følgende kommandokall. Hvis den returnerte markøren er 0 etter en eller flere iterasjoner, betyr det at skanneprosessen er over. Alle de sorterte settmedlemmene returneres på dette tidspunktet. Denne prosessen kalles en full iterasjon. Som du kunne se, beholder ZSCAN-kommandoen sin tilstand kun ved å bruke en markør som fører til en begrenset tilstandsbevissthet. Derfor er følgende ulemper knyttet til ZSCAN-kommandoen.

• Det samme elementet kan komme tilbake i flere iterasjoner.
• Hvis et medlem ikke er til stede ved starten av skanningsprosessen, er det en sannsynlighet for ikke å returnere det medlemmet under en full iterasjon.

I tillegg er det ingen garanti for antall returnerte medlemmer. I noen tilfeller, hvis det sorterte settet er veldig lite, kan alle medlemmene returneres i den aller første iterasjonen. Fordi Redis bruker et spesielt enkelttildelingspakket kodingsformat for å holde medlemmene til et maksimalt antall varer er nådd. ZSCAN-kommandoen kan bare returnere en markør hvis den skannede datastrukturen er representert som en hashtabell.

Syntaks:
ZSCAN-kommandoen bruker nesten samme syntaks som SCAN-kommandoen bortsett fra at den godtar en sortert settnøkkel som det første argumentet. Kommandosyntaksen med de tillatte argumentene er som følger:

sortert_sett_nøkkel : Nøkkelen til det sorterte settet.
Markør : Markørverdien starter fra 0 og slutter på 0 hvis det er en full iterasjon.

Følgende argumenter er valgfrie:

KAMP : Et mønster for å matche når du henter elementene i hver iterasjon. Bare de matchede medlemmene returneres.
TELLE : Det omtrentlige antallet medlemmer som skal returneres i hver iterasjon.

Det returnerte resultatsettet per iterasjon inneholder et par elementer. Den første delen er et 64-bits usignert heltall som representerer markøren som skal sendes til neste samtale. Den neste delen er en rekke medlemmer og tilhørende score.

Bruk Case 1 – Hent alle medlemmene og deres fullførte oppdrag i et nettspill

La oss anta at et online spillselskap opprettholder en ledertavle ved hjelp av Redis sortert sett. Siden massive brukere aktivt spiller spillet, trenger de en måte å hente hver spiller og deres tilhørende poengsum som er antall fullførte oppdrag. Det er et must å utføre hentingen uten å blokkere serveren. Så anbefalingen er å bruke ZSCAN-kommandoen som følger:

Først lager vi et sortert sett med noen spillere og det fullførte antallet oppdrag.

Nå kan vi iterere over medlemmene i det sorterte settet som følger:

Produksjon:

Markørverdien er 0 i det returnerte resultatsettet, noe som betyr at alle medlemmene returneres på slutten av den første iterasjonen. I dette tilfellet, fordi antallet medlemmer er lite, representerer Redis disse medlemmene ved å bruke en enkelt-allokeringspakket koding. Derfor, inntil en maksimal pakkestørrelse eller medlemsantall er nådd, returnerer kommandoen alle medlemmene i det sorterte settet. Dette kalles en full iterasjon. For på slutten av den første iterasjonen mottar vi alle ti medlemmene og deres poeng. Hvis vi har hundrevis av medlemmer, er det representert som en hash-tabell i minnet. Så det tar flere iterasjoner å returnere alle medlemmene.

COUNT-parameteren kan brukes til å begrense antall medlemmer som returneres i en iterasjon. Som standard er dette argumentet satt til 10. Hvis det sorterte settet består av hundrevis av medlemmer, er det representert av en hash-tabell i minnet. Så antallet returnerte medlemmer er rundt ti per iterasjon. Verdien til COUNT-argumentet ignoreres hvis det sorterte settet er for lite.

Bruksfall 2 – Hent spillerne hvis navn starter med bokstaven “J”

ZSCAN-kommandoen kan brukes til å filtrere ut de returnerte medlemmene basert på en mønstermatch. I så fall må MATCH-argumentet spesifiseres.

La oss bruke det samme eksempelet fra forrige brukstilfelle. Kravet er å hente spillerne hvis navn starter med bokstaven 'J'. Det er bare å implementere den neste kule funksjonen knyttet til spillet. MATCH-argumentet kan spesifiseres som følger:

Dette bør ideelt sett returnere to medlemmer som heter Jeremy og John.

Konklusjon

Oppsummert brukes ZSCAN-kommandoen til å iterere over medlemmene og poengsummene til et Redis-sortert sett. Denne kommandoen oppfører seg på samme måte som SCAN-kommandoen, bortsett fra at ZSCAN-kommandoen godtar set-nøkkelen som det første argumentet. Som diskutert i brukstilfellene, kan ZSCAN-kommandoen brukes på forskjellige måter ved å spesifisere MATCH- og COUNT-argumentene der du kan hente medlemmene og tilhørende poengsum som samsvarer med et spesifikt mønster og begrense antall returnerte medlemmer per iterasjon. Samlet sett kan ZSCAN-kommandoen være nyttig når du henter medlemmene i et sortert sett uten å blokkere serveren eller klienten.