Redis Sentinel vs Cluster

Redis kan identifiseres som en ekstern ordbokserver som hovedsakelig er designet for hastighet. I tillegg brukes den mye som en hurtigbuffer og NoSQL-database. Som en database eller hurtigbuffer er det viktig å gi en høy frekvens av datatilgang, høy tilgjengelighet, databeskyttelse og skalerbarhetsfunksjoner. Redis introduserte Sentinel og Cluster Solutions for å adressere de nevnte aspektene.

Redis Cluster

Redis Cluster -teknologien som ble introdusert fra versjon 3.0 muliggjør den horisontale skaleringen for en gitt redis -distribusjon. Med Redis -klynger deles dataene over flere klyngeknuter som gir et konsistent og pålitelig datatjenestelag for applikasjoner.

Det er et must å ha minst tre mesternoder for en klynge å fungere ordentlig. I tillegg skal hver masternode ha minst en enkelt slaveknute. Videre muliggjør Redis -klynger høy tilgjengelighet opp til en viss grad ved å fremme en slaveknute tilknyttet en mislykket masterforekomst i en maskinvare/programvare eller nettverksfeil.

Hver klyngeknute kommuniserer med andre noder ved hjelp av en binær protokollbasert node-til-node kommunikasjonskanal. I tillegg er hver node åpen for klientforbindelser ved å bruke standard TCP -port.

Følgende er en skisse på høyt nivå av en grunnleggende Redis-klyngekonfigurasjon:

Fordeler:

• Data Sharding
  • Dataene deles mellom flere noder, og de kan justeres dynamisk.
  • Siden det ikke er noe sentralt kontrollsenter, deles dataene automatisk delt mellom noder.
• Skalerbarhet
  • En klynge kan skalere opptil 1000 noder. Noder kan fjernes eller tilsettes dynamisk.

• Automatisk failover

• • Redis Cluster støtter master-slavearkitektur, og den muliggjør den innebygde master failover-teknikken.

Ulemper:

• Ikke helt veldig tilgjengelig
  • I tilfelle en stor fiasko, kan de fleste av masternodene gå ned som får hele klyngen til å gå ned.
• Det høye antallet noder per enkelt klynge
  • Det er et must å ha minst tre masterforekomster og en enkelt slaveknute per master som ender opp med seks noder for å sette opp en riktig fungerende Redis -klynge.
• Ingen garanti for datakonsistens
  • Redis Cluster Master Replication behandles asynkront, og det kan påvirke konsistensen.
• Mangel på klientbibliotekstøtte for Redis -klyngen
  • Det er et minimalt antall klientbiblioteker som støtter implementeringene av Redis Cluster.
• Enkeltlags replikasjon
  • Redis Cluster Master Replication Architecture tillater bare et enkelt lag. En gitt slaveforekomst kan bare gjenskape masternoden.
• Redis Cluster kan miste anerkjente skriver i noen scenarier

• Datahåndtering er mer komplisert

• • På grunn av dataene om data, bør klyngeadministratorer administrere flere RDB- og AOF -filer. Videre er det nødvendig med ekstra innsats for å samle utholdenhetsfiler fra flere noder for å lage en sikkerhetskopi.

Redis Sentinel

Redis Sentinel er en tilnærming med høy tilgjengelighet for Redis-distribusjoner som kjører som et eget program i bakgrunnen. Det bringer mange funksjoner til Redis -distribusjonene dine ved hele tiden å sjekke statusen for master- og slaveknute, og varsle de betydelige endringene relatert til de overvåkede forekomstene via en API, initialisere den automatiske failover -prosessen når en masterfeil oppstår, og fungerer som en kilde til autoritet for klienter å finne ut den for tiden aktive Redis Master Node IP -adresse.

Et Redis Sentinel -oppsett kan implementeres ved hjelp av minst tre Sentinel -noder som kan unngå de fleste problemene i en gitt Redis -distribusjon. Videre, i en gitt Sentinel -konfigurasjon, definerer quorumverdien minimum antall sentinelknuter som bør bekrefte når en master mislykkes.

Generelt brukes Redis Sentinel først og fremst for å støtte den høye tilgjengeligheten av en Redis -database der den presterer bedre enn i grupperingsmetoden.

Følgende er en illustrasjon på høyt nivå av en minimal Redis Sentinel-konfigurasjon:

Fordeler:

• Minimalt antall noder
  • En helt fungerende Redis Sentinel -distribusjon kan dannes med tre noder.
• Svært tilgjengelig
  • Redis Sentinel -distribusjon kan overleve kritiske nodesvikt uten menneskelig innblanding.
  • Den kan fungere når minst en enkelt masterinstans er tilgjengelig selv om hver slave er nede.
• Forbedret masterreplikasjon
  • I Redis Sentinel -distribusjon kan flere slaver gjenskape en gitt masterinstans.
• Enkelhet og fleksibilitet

• Redis Sentinel er veldig enkelt å vedlikeholde og har også fleksible konfigurasjonsalternativer.

Ulemper:

• Ingen sharding støttet
  • Data Sharding er ikke mulig. Derfor kan store datasett tilgjengelighet føre til at ytelsen nedbryter.
• Mangel på skalerbarhet
• Utdaterte leser
  • Vanligvis serverer slaveknutene leser i Redis Sentinel -utplasseringen. På grunn av den asynkrone replikasjonen, er det kanskje ikke oppdatert.
• Redis Sentinel bør støttes av klientbiblioteket
• Slaveknute fungerer ikke som en backup -node

Redis Sentinel vs Cluster

Redis Cluster og Sentinel er to tilnærminger der hver adresserer forskjellige aspekter relatert til en Redis -distribusjon. For å fremheve, er Redis Cluster -tilnærmingen mer egnet for kompliserte implementeringer som omhandler massive datasett der den gir automatisk data sharding for bedre lese/skrive spørringsytelse, automatisk master failover og replikering med høy tilgjengelighet opp til en viss grad. Videre kan Redis Cluster Nodes skaleres uanstrengt.

På den annen side er Redis Sentinel mer fokusert på mindre implementeringer med høy tilgjengelighet i tankene.

Tilgjengelighet

Redis Cluster støtter ikke helt høy tilgjengelighet. For hvis flertallet av mestrene ikke er tilgjengelige, kan klyngen gå ned. I motsetning til klyngetilnærmingen, tilbyr Redis Sentinel høy tilgjengelighet uten menneskelig innblanding. Det viktigste er at Sentinel kan overleve selv med en enkelt løpende masterinstans når en kritisk feil oppstår.

Data Sharding

Redis Cluster tilbyr sharding -muligheter der dataene er distribuert mellom flere noder når klienter har nettverkstilgang til alle nodene. Det muliggjør økt ytelse og datalagringskapasitet.

På den annen side tilbyr Redis Sentinel ikke sharding -evner. Fordi shardingen forårsaker ubalanseutnyttelsen av mesteren og slaven.

Replikering

Begge tilnærminger tilbyr master replikering med noen begrensninger. Redis Sentinel tillater replikering for flere lag der flere slaveknuter kan replikere fra en gitt masterinstans. I kontrast tillater ikke Redis Cluster -tilnærmingen replikering for flere lag. Det er bare i stand til å gjenskape masterforekomsten til en enkelt slaveknute. Begge tilnærminger går på akkord med konsistensen på grunn av async replikasjon.

Skalerbarhet

Redis -klynger er svært skalerbare. Den støtter opptil tusen noder i et gitt enkelt klyngeoppsett. Videre tillater klynger tilsetning og fjerning av noder dynamisk og uanstrengt. Redis Sentinel er ikke skalerbar og skriver blir rettet mot masterforekomsten, og følgelig er Sentinel ikke i stand til å håndtere leseseparasjonsproblemene.

Arkitektur

En fullt funksjonell Redis Sentinel kan bygges med bare tre noder. Men for å sette opp en Redis -klynge, krever den minst tre masternoder og tre slaver festet til dem, noe som er mer kostbart enn i Redis Sentinel -distribusjon.

Konklusjon

For å oppsummere er Redis Cluster -tilnærmingen mer fokusert på komplekse distribusjoner når høy skalerbarhet, høy ytelse og høy datalagring er viktig og den høye tilgjengeligheten ikke er betydelig. På den annen side er Redis Sentinel først og fremst bygget for enkle applikasjoner som hovedsakelig er fokusert på høy tilgjengelighet. Sammenlignet kommer begge løsningene med sine fordeler og ulemper, men for å støtte sluttbrukerne med mer finjustert redis-distribusjon.