Når du først begynner å bruke Redis, er det lett å tro at du aldri trenger å skalere det utover standardinnstillingene. Problemet er at når applikasjonen din vokser, vil du til slutt trenge mer minne, CPU og gjennomstrømningskapasitet for å støtte dine forretningsbehov. I denne artikkelen viser vi deg hvordan Redis -klyngen skalerer med sharding for å gi deg den ekstra kapasiteten du trenger for å drive virksomheten din jevnt og vokse inn i fremtiden. Vi lærer spesifikt hvordan Redis -klyngen gir høy gjennomstrømning med sharding.

Skalerbarhet

Det er to vanlige tilnærminger til å skalere en server: vertikal skalering og horisontal skalering. Vertikal skalering eller skalering er der du legger til mer strøm og ressurser til serveren din, for eksempel mer CPUer, minne og lagring, noe som er kostbart. På den annen side legger horisontal skalering flere noder til din eksisterende ressursbasseng. Dette kalles skalering ut. Så basert på dine begrensninger og krav, er det opp til deg å ha en enkelt større serverforekomst eller distribuere flere servernoder.

Anta at du har 100 GB RAM og trenger å holde 200 GB data. I dette tilfellet har du to valg:

• Skala opp ved å legge mer RAM til systemet
• Skala ut ved å legge til en annen serverforekomst med 100 GB RAM

Hvis du har nådd den maksimale RAM -grensen i infrastrukturen din, er det den ideelle tilnærmingen. I tillegg vil skaleringen øke databasegjennomstrømningen med en enorm margin.

Redis Sharding

Det er et kjent faktum at Redis opererer på en enkelt tråd. Så Redis er ikke i stand til å bruke flere kjerner av serverens CPU for å behandle kommandoer. Derfor gir ikke flere CPU -kjerner mye gjennomstrømning eller ytelse med Redis. Det er ikke tilfelle med å dele opp dataene dine mellom flere serverforekomster. Legge til flere servere og distribuere datasettet blant dem som muliggjør behandling av klientforespørsler parallelt, noe som øker gjennomstrømningen. I tillegg kan den samlede ytelsen øke nær lineært.

Denne tilnærmingen til å dele eller distribuere data mellom flere servere med skalering i tankene kalles Sharding. Alle serverne som lagrer deler av data kalles Skår.

Hvordan sharding gjøres - algoritmisk sharding

En av de største bekymringene med Sharding var hvordan du finner en gitt nøkkel blant flere Redis -noder. Fordi en gitt nøkkel kan lagres i alle tilgjengelige skjær, er det ikke det beste alternativet å spørre alle skjær for å finne en spesifikk nøkkel. Så det skal være en måte å kartlegge hver tast til en spesifikk skjær, og Redis bruker en algoritmisk sharding -strategi.

Den vanligste tilnærmingen er å beregne en hasjverdi ved bruk av Redis -nøkkeltnavn og modulo. Del den deretter med de tilgjengelige redis -skjærene i systemet.

Hash_Slot = CRC16 (Key) Mod 16384

Det er en ganske god løsning så lenge det totale antallet skjær er konstant. Hver gang du legger til en ny Reids Server -forekomst, kan den resulterende verdien for en gitt nøkkel endres siden det totale antallet skjær har økt. Det vil ende opp med å spørre feil Redis Shard. Derfor bør du følge resharding -prosessen ved å beregne den nye skjæren for hver tast og overføre data til riktig server, som er tungvint og ikke en triviell oppgave hvis det totale tellingen din øker fra tid til annen.

Redis bruker en ny logisk enhet kalt en hash -spor For å forhindre dette problemet. Flere hash -spor er tilgjengelige for en gitt skjær, og et enkelt hash -spor kan holde flere redis -tastene. Det er 16384 hash -spor i en Redis -databaseklynge som forblir uendret. Modulo -divisjonen er utført med antall hasjspor i stedet for Shard Count. Det gir riktig plassering av hasjsporet for den spesifiserte tasten selv når antallet skjær har økt. Det forenkler omhardingsprosessen ved å flytte hasjsporene fra en skjær til den nye som deler data over de forskjellige Redis -forekomstene i henhold til krav.

Fordelene med Redis Sharding

Redis Sharding muliggjør flere fordeler for databasesystemet ditt med minimale endringer.

Høy gjennomstrømming

Siden Redis er entrådet, kan behandling av flere klientforespørsler ikke behandle parallell med flere CPU-kjerner. Så å legge til nye skjær eller serverforekomster garanterer at du kan utføre Redis -operasjoner parallelt. Det øker operasjonene per sekund i Redis -databasen din, noe som til slutt gir deg høy gjennomstrømning.

Høy tilgjengelighet

Med Sharding-tilnærmingen kan Redis-klyngen sette opp en master-replica-arkitektur som sikrer høy tilgjengelighet og holdbarhet.

Les kopier

Sharding lar deg oppbevare en eksakt kopi av dataene dine og gi leseoperasjoner gjennom separate Redis -forekomster, noe som øker ytelsen til utførelsen av lesesøk.

Bortsett fra disse fordelene, kan sharding forårsake situasjoner. Så det anbefales et merkelig antall skjær i Redis -klyngen.

Konklusjon

For å oppsummere, deler Redis Sharding data mellom flere servere, noe som muliggjør skalering og høy gjennomstrømning for databasen din. Som diskutert bruker Redis en algoritmisk sharding -strategi for å peke klientforespørsler til riktig skjær. Dette har noen ulemper når det totale antallet skjær øker. Så i stedet for det totale antallet skjær, bruker Redis antall hashspor for å beregne riktig skjær. Med Sharding introdusert gir Redis -databaser høy tilgjengelighet, høy gjennomstrømning og høy ytelse.